Ad Hoc Networking for Unmanned Ground Vehicles: 

Design and Evaluation at Command, Control, 

Communications, Computers, Intelligence, Surveillance and 

Reconnaissance On-The-Move 

by Barry J. O’Brien, David G. Baran, and Brian B. Luu 

ARL-TR-3991 November 2006 

Approved for public release; distribution 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 

Adelphi, MD 20783-1197 

ARL-TR-3991 November 2006 

Ad Hoc Networking for Unmanned Ground Vehicles: 

Design and Evaluation at Command, Control, 

Communications, Computers, Intelligence, Surveillance and 

Reconnaissance On-The-Move 

Barry J. O’Brien, David G. Baran, and Brian B. Luu 

Computational and Information Sciences Directorate, ARL 

Approved for public release; distribution 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)

November 2006 

2. REPORT TYPE 

Final 

3. DATES COVERED (From - To) 

April 2006 to August 2006 

5a. CONTRACT NUMBER 

5b. GRANT NUMBER 

4. TITLE AND SUBTITLE 

Ad hoc Networking for Unmanned Ground Vehicles: Design and Evaluation at 

Command, Control, Communications, Computers, Intelligence, Surveillance 

and Reconnaissance On-The-Move 

5c. PROGRAM ELEMENT NUMBER 

5d. PROJECT NUMBER 

5e. TASK NUMBER 

6. AUTHOR(S) 

Barry J. O’Brien, David G. Baran, and Brian B. Luu 

5f. WORK UNIT NUMBER 

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

U.S. Army Research Laboratory 

ATTN: AMSRD-ARL-CI-CB 

2800 Powder Mill Road 

Adelphi, MD 20783-1197

8. PERFORMING ORGANIZATION 

 REPORT NUMBER 

ARL-TR-3991

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

U.S. Army Research Laboratory 

2800 Powder Mill Road 

Adelphi, MD 20783-1197 

11. SPONSOR/MONITOR'S REPORT 

 NUMBER(S) 

12. DISTRIBUTION/AVAILABILITY STATEMENT 

Approved for public release; distribution unlimited. 

13. SUPPLEMENTARY NOTES 

14. ABSTRACT 

The U.S. Army Research Laboratory (ARL) participated in the command, control, communications, computers, intelligence, 

surveillance and reconnaissance (C4ISR) On-the-Move (OTM) experiment that was held at Fort Dix, New Jersey, during the 

summer of 2006. The C4ISR OTM experiment was designed to examine the effectiveness that advanced C4ISR technologies 

have on an Army Future Combat Systems (FCS)-based Infantry Company and Reconnaissance Troop. The experiment 

included live Soldier exercises, with each Soldier being connected to a battlefield tactical network. ARL’s objective in the 

exercise was to demonstrate system-level integration of developing technologies for small unit combat operations aimed at 

improving situational awareness. ARL brought to the experiment expertise in unattended ground sensing technology, wireless 

mobile ad hoc communication, and information fusion. The ARL C4ISR system included multimodal unattended ground 

sensors, a trip wire imager, multiple human-portable robotic vehicles (PackBots), and an unmanned scout/light cargo carrying 

robotic vehicle (R-Gator). 

This report discusses the work done at ARL on the mobile ad hoc networking system for controlling robotic assets, which was 

created for the C4ISR OTM experiment. Further, it examines the results of a number of field tests performed in preparation 

for and during the experiment. 

15. SUBJECT TERMS

Ad hoc, networking, UGV, C4ISR 

16. SECURITY CLASSIFICATION OF:

19a. NAME OF RESPONSIBLE PERSON

Barry J. O’Brien 

a. REPORT 

Unclassified 

b. ABSTRACT 

Unclassified 

c. THIS PAGE 

Unclassified 

17. LIMITATION 

OF ABSTRACT 

SAR 

18. NUMBER 

OF PAGES 

36 19b. TELEPHONE NUMBER (Include area code) 

301-394-1222 

Standard Form 298 (Rev. 8/98) 

Prescribed by ANSI Std. Z39.18 
iii 

Contents 

List of Figures v

List of Tables v

1. Introduction 1

2. ARL Involvement 1

3. Mobile Ad Hoc Networks 3

4. Design and Implementation 7

4.1 Linksys Router Software Installation and Configuration................................................7 

4.2 PackBot Payload Design .................................................................................................7 

4.3 Gator Payload Design......................................................................................................9

4.4 Drop-off Node Design...................................................................................................10 

4.5 OCU Node Design.........................................................................................................12 

5. Test and Analysis 13

5.1 Initial Robotic Field Test (Fort Dix, New Jersey).........................................................15 

5.1.1 Objectives..........................................................................................................15 

5.1.2 Results ...............................................................................................................16 

5.1.3 Discussion .........................................................................................................16 

5.2 Informal Robotic Field Test (Adelphi Laboratory Center) ...........................................18 

5.2.1 Objectives..........................................................................................................18 

5.2.2 Results ...............................................................................................................18 

5.2.3 Discussion .........................................................................................................18 

5.3 Formal Robotic Field Test (Adelphi Laboratory Center)..............................................19 

5.3.1 Objectives..........................................................................................................19 

5.3.2 Results ...............................................................................................................19 

5.3.3 Discussion .........................................................................................................20 

5.4 Preliminary UGV Evaluation (Fort Dix, New Jersey) ..................................................21 

5.4.1 Objectives..........................................................................................................21 

5.4.2 Results ...............................................................................................................21 
iv 

5.4.3 Discussion .........................................................................................................22 

5.5 UGV Evaluation (Fort Dix, New Jersey) ......................................................................22 

5.5.1 Objectives..........................................................................................................22 

5.5.2 Results ...............................................................................................................23 

5.5.3 Discussion .........................................................................................................24 

5.6 C4ISR On-The-Move Experiment (Fort Dix, New Jersey) ..........................................25 

6. Conclusion and Future Work 26

Distribution List 27
v 

List of Figures 

Figure 1. Representation of a MANET topology with subnets attached to some MANET 

nodes. ...................................................................................................................................... 5 

Figure 2. A VPN tunnel connecting subnets s1 and s6.................................................................. 6 

Figure 3. PackBots showing ARL ad hoc payloads....................................................................... 8 

Figure 4. Internals of ARL ad hoc drop-off node. ....................................................................... 11 

Figure 5. ARL OCU showing ad hoc node.................................................................................. 13 

Figure 6. ARL OCU showing operation of CollectControl......................................................... 14 

Figure 7. Initial robotic field test site at Fort Dix, New Jersey.................................................... 15 

Figure 8. PackBot operating at MOUT site. ................................................................................ 24 

List of Tables 

Table 1. Results of initial robotic field test.................................................................................. 16 
vi 

INTENTIONALLY LEFT BLANK
1 

1. Introduction 

The U.S. Army Research Laboratory (ARL) participated in the command, control, 

communications, computers, intelligence, surveillance and reconnaissance (C4ISR) On-theMove (OTM) experiment that was held at Fort Dix, New Jersey, during the summer of 2006. 

The experiment was hosted by the Communications and Electronics Research Development 

Engineering Center (CERDEC) Special Projects Office (SPO) C4ISR Integration Test bed, Fort 

Monmouth, New Jersey. 

The C4ISR OTM experiment was designed to examine the effect that advanced C4ISR 

technologies have on situational awareness (SA) of an Army Future Combat Systems (FCS)-

based infantry company and reconnaissance troop. The experiment included live Soldier 

exercises, with each Soldier being connected to a battlefield tactical network. Also connected to 

the tactical network was a suite of manned and unmanned sensor assets controlled via a cohesive 

command and control environment1. 

ARL’s objective in the exercise was to demonstrate system-level integration of developing 

technologies for small unit combat operations aimed at improving SA. ARL brought expertise in 

unattended ground sensing technology, wireless mobile ad hoc communication, and information 

fusion to the experiment. The ARL C4ISR system included multimodal unattended ground 

sensors, trip wire imagers, multiple human-portable robotic vehicles (PackBots), and an 

unmanned scout/light cargo carrying robotic vehicle (R-Gator). These disparate technologies 

were integrated into an overall C4ISR system with the use of a combination of proprietary and 

commercial off-the-shelf (COTS) components, and they communicated wirelessly via various 

methods. Users can control the system in a number of ways, including using a remote mobile 

platform mounted in a tactical high mobility multipurpose wheeled vehicle (HMMWV) or via an 

operator control unit (OCU) carried by a dismounted Soldier. In addition, the ARL C4ISR 

system was integrated into the Force XXI Battle Command, Brigade and Below (FBCB2) 

display suite, which provided users with the capability of controlling and accessing data from 

multiple systems at a central location. 

2. ARL Involvement 

Four of the six technology directorates at ARL participated in the C4ISR OTM experiment. The 

Weapons and Materials Research Directorate (WMRD) provided a number of unmanned aerial 

vehicle (UAV) technologies, the Human Research and Engineering Directorate (HRED) 

 1

C4ISR OTM Program Overview, www.c4isrotm.net (cached page only). 
2 

provided operational and usability assessments, the Sensors and Electron Devices Directorate 

(SEDD) provided multimodal unattended ground sensors (UGS), and the Computational and 

Information Sciences Directorate (CISD) provided unmanned ground vehicle (UGV) 

technologies and integration software. This report focuses on the work that CISD performed for 

the experiment. 

HRED played a significant role in gathering useful feedback from the Soldier end users of the 

unmanned systems brought by CISD and SEDD. By administering surveys to the dismounted 

Soldiers during the exercises, HRED personnel were able to gain insight into whether the new 

technologies improved Soldiers’ perceived SA, to gain immediate feedback about how the 

Soldiers were using ARL technologies, and to document any issues that arose during their use in 

the field. 

CISD and SEDD collaborated on integration efforts in preparation for the experiment. SEDD 

contributed a suite of UGSs to the experiment and wanted to integrate into CISD’s command and 

control software so that sensor data could be displayed on a mapping system. Working closely 

with CERDEC, the two directorates integrated communications from the sensors to platoon-level 

vehicles using CISD’s Blue Radio, a low power and low data rate radio designed for sensor 

networking. Further, data provided by the UGSs was integrated into two pieces of CISD 

software, Sensed Object Server (SOS) and Tactical Object Server (TOS). These applications ran 

on a server in the platoon-level vehicle. SOS converted low-level data from sensors into a more 

usable format, which TOS then converted into tactical symbols that could be displayed on 

FBCB2, the mapping system used at C4ISR OTM, via a CERDEC message translator called the 

Conduit Gateway. These integration efforts allowed sensor data to appear as speed, position, and 

track (SPOT) reports in the same manner as user-generated reports from the unmanned assets. 

Because of the high level of collaboration among CISD, SEDD, and CERDEC, this system was 

able to be brought on line in the field in less than one day. 

The other pieces of technology that CISD brought to the experiment were its unmanned systems 

and corresponding mobile ad hoc network (MANET). CISD brought two robotic platforms to 

the experiment. The first was the PackBot2

 Explorer, manufactured by iRobot, which acted as 

the FCS small unmanned ground vehicle (SUGV) surrogate. The second platform was the 

R-Gator3, also manufactured by iRobot, which acted as the FCS armed robotic vehicle platform 

in its reconnaissance, surveillance, and target acquisition (ARV-RSTA) configuration. CISD 

removed all iRobot proprietary application software from both platforms, choosing instead to 

write its own robotic control and network architecture software, giving it a more robust feature 

set while maintaining its openness and extensibility. Connecting each robot to its OCU as well 

as to other robots was a MANET built from COTS components that had been altered by CISD to 

operate a modified version of open-source MANET software. The MANET features allowed the 

 2

PackBot is a registered trademark of iRobot, Inc. 

3

R-Gator is a trademark of iRobot, Inc. 
3 

network operational range to be extended by the emplacement of CISD designed ad hoc drop-off 

nodes along a chosen path, thus giving the network traffic the ability to “hop” from one node to 

the next, even on non-line-of-sight (NLOS) paths. 

This report focuses on the design, implementation, and results of the MANET that was 

implemented for robotic control in the C4ISR OTM experiment. We discuss the research 

relating to MANET design and the low-cost COTS equipment used to implement the design. 

Further, discussion focuses on the drop-off nodes, highlighting their low cost and ability to 

extend the MANET. Finally, we discuss the results of numerous field experiments and 

evaluations performed in preparation for and during the C4ISR OTM experiment. 

3. Mobile Ad Hoc Networks 

A MANET is generally defined as a wireless, self-configuring ad hoc network that consists of 

mobile nodes connected together by wireless links. These mobile nodes can act as routers to 

forward routing information and data to each other, maintaining network connectivity among 

them. By exchanging routing information between nodes, these routers can freely move and 

organize themselves into a self-configuring network of random shapes or topologies. 

Because of its versatility, a MANET is a very useful tool for meeting Army battlefield 

communication requirements. The mobility provided by a MANET is not only a key factor for 

survivability on the battlefield but also provides convenience and flexibility in executing the 

Army mission. The ad hoc capabilities allow the Army to deploy and use network 

communications without a fixed infrastructure. The MANET can be quickly deployed in urban 

environments or on battlefields where network infrastructure can be destroyed, unreliable, or 

unavailable. The self-configuration capability of a MANET allows mobile Army units be very 

adaptive to topological changes without manual reconfiguration of the network. 

ARL has researched MANETs and their application for military uses. Several self-configuration 

protocols are used for implementing a MANET, but there are two main MANET protocol 

groups: proactive and reactive. In reactive MANET protocols (RMPs), routing information 

between nodes is determined when communications are needed. Thus, communication overhead 

is less but network communication latency is high. Conversely, in proactive MANET protocols 

(PMPs), routing information of nodes is constantly exchanged on the network, yielding high 

network overhead but low network latency. An open source version of a proactive MANET 

protocol is called Optimized Link State Routing Daemon (OLSRD)4

. OLSRD is an 

implementation of the Optimized Link State Routing (OLSR) protocol. 

 4

Developed by Andreas Tønnesen and Thomas Lopatic (www.olsr.org). 
4 

Typically, MANET nodes have the capability to communicate with each other but do not have 

any specialized processing capabilities to perform dedicated tasks such as computation, video or 

file serving. Dedicated computer nodes for specific tasks must be equipped with both a wireless 

local area network (LAN) interface and the MANET protocol in order to communicate in the 

MANET environment. These requirements will make dedicated computer nodes less mobile 

since they will be larger and heavier and will consume more power. “MANETized” computer 

nodes are not readily available as already defined COTS products since there is limited demand 

for MANET capabilities outside military applications, and no actual MANET protocol standards 

have been established. The solution is to develop and implement gateway capabilities from 

regular computer networks such as Ethernet to MANET and vice versa. With this 

implementation, the MANET nodes communicate with one another while the dedicated 

computer nodes are connected to the MANET nodes through a regular network interface. This 

technique is called the sub-network gateway to MANET technique. 

For implementation of a MANET, ARL has employed the ad hoc capability of wireless LANs 

such as Institute of Electrical and Electronics Engineering (IEEE) 802.11a/b/g as a means to 

achieve mobility. The IEEE 802.11g wireless standard is the best choice since it provides faster 

data rates (54 Mbps maximum) and farther wireless operational distance than the IEEE 802.11a 

or IEEE 802.11b protocols. 

In 2004, for the Department of Defense (DoD) Horizontal Fusion program, ARL developed 

MANET nodes called black ad hoc nodes with the support of BBN Technologies and Telecordia, 

Inc. The MANET protocol used for the black ad hoc node was Hazy Sighted Link State (HSLS), 

which was developed and licensed by BBN Technologies. Since the black ad hoc nodes were 

designed specifically for the Horizontal Fusion program and were the first experimental 

MANET, they were limited in capability and performance. 

In 2006, with the maturity and proliferation of wireless LANs, ARL developed new MANET 

nodes, called blue ad hoc nodes, which have a smaller form factor and better performance. As a 

cost-saving measure, the blue ad hoc nodes were built with Linksys wireless LAN routers and 

the open source OLSRD. The Linksys router is built with an internal 100-mW amplifier for 

802.11g wireless LAN protocol which allows for long distance wireless operation (as far as 

500 m) without the use of high-gain antennae. It is also equipped with two wired Ethernet 

10/100 interfaces to allow implementation of the sub-network gateway to MANET technique for 

connecting dedicated computer nodes. With the sub-network gateway technique, the subnetwork (subnet) attached to a MANET node is advertised in the MANET environment so that 

the gateway to this subnet is through its MANET node. Figure 1 depicts a MANET topology 

with subnets attached to some MANET nodes. 
5 

M1

S1

M3

S3

M2

S2

M4

M5

M8

S7

M6

S6

Figure 1. Representation of a MANET topology with subnets attached to some MANET nodes. 

Examples of subnets used by ARL are robotic platforms, robotic OCUs, and mobile video 

servers. By connecting to a MANET node, the robotic OCU can maneuver a remote robot 

connected to another MANET node. Similarly, mobile video servers attached to a MANET node 

can provide streaming video to any non-MANET nodes on subnets that are connected to 

MANET nodes. 

Intermediate MANET nodes forward network information and data of other MANET nodes. 

Thus, MANET nodes can be used to extend the operative range of linked nodes by hopping 

between MANET nodes. These intermediate nodes do not have to be connected to any subnets 

and are called drop-off nodes. 

To minimize cost and developed time, the Battlefield Communication Network Branch (CI-CN) 

of ARL’s CISD developed ad hoc nodes using Linksys wireless LAN routers (models 

WRT54GS and WRTSL54GS) and open source software (OpenWRT5

, OLSRD and OpenVPN6). 

The network facility of the Linksys WRTSL54GS consists of two wired 10/100 Ethernet 

interfaces and one wireless LAN interface (capable of IEEE 802.11b/g). OpenWRT is a version 

of the Linux operating system with a small footprint specifically designed for embedded devices. 

Two other important software components used in the ad hoc nodes for the C4ISR OTM 

experiment were OLSRD, an open-source proactive MANET routing software, and OpenVPN, 

an open-source virtual private network (VPN) software used for security and encryption. 

 5

OpenWRT was developed by Mike Baker (openwrt.org). 

6

OpenVPN is a trademark of OpenVPN Solutions LLC. 
6 

Secure communications in the MANET are achieved with encryption provided by Wired 

Equivalent Privacy (WEP) and OpenVPN. The WEP protocol, which is part of the IEEE 802.11 

wireless networking standard, encrypts network frames before transmitting to the air medium. 

The WEP encryption provides confidential communication at the physical and data link layer, 

known as layers 1 and 2, respectively, in the Open System Interconnection (OSI) model of 

communication network. For strong encryption, a 128-bit-key encryption is used for the WEP of 

blue ad hoc nodes. Although there are security limitations of WEP when one is using short 

encryption keys (40 or 64 bits), WEP encryption is good enough to provide protection for 

MANET routing information, which is usually not as protected as internet routing information. 

The main function of OpenVPN is to provide secure communication of private networks over 

unsecured public networks such as the internet. To achieve secure communication, OpenVPN 

creates cryptographic tunnels through public networks to link private networks together. For 

application in a MANET, OpenVPN is used to create VPN tunnels to securely link subnets, 

which are attached to MANET nodes. OpenVPN provides communication encryption at the 

network layer (layer 3 of the OSI model), establishing an end-to-end communication encryption 

between two MANET nodes. With cryptographic tunneling protocols, OpenVPN enables 

confidentiality (privacy), authentication (sender and receiver identity), and integrity (unaltered 

data) for communications in a MANET. Figure 2 illustrates a VPN tunnel connecting subnets s1 

to subnet s6. 

M1

S1

M3

S3

M2

S2

M4

M5

M8

S7

M6

S6

Figure 2. A VPN tunnel connecting subnets s1 and s6.
7 

4. Design and Implementation 

4.1 Linksys Router Software Installation and Configuration 

Before ad hoc communication payloads were designed to provide network connectivity to all the 

system assets in the MANET, configuration of the COTS wireless routers had to be performed. 

For each of the nodes, configuration began with a new, unmodified Linksys wireless LAN 

router. 

The first step of the configuration process was to replace the proprietary firmware with opensource software that contained all the software components needed for the MANET, namely, 

OpenWRT, OLSRD, and OpenVPN. This .bin file was flashed onto the router via the webbrowser-based interface and was rebooted. 

Following the firmware installation, a telnet connection to the router via the default internet 

protocol (IP) address7 was established. A manual reboot was then performed to allow 

OpenWRT to complete initialization of the new Linux file system. 

The telnet connection was then re-established, and a password was set on the router to prevent 

unauthorized access. A set-up script file and tar files needed by the script were securely copied 

to the /tmp directory. The set-up tar file was extracted into the /tmp folder, and then the set-up 

script was executed. The node host name and IP address were set as desired when prompted by 

the script, with a 192.168.x.1 format. The settings were saved to memory with the nvram 

command, and the router was rebooted to finish IP configuration. 

The last step was to configure the VPN. We accomplished this by running a vpn configuration 

script, which prompted for the two IP addresses in the VPN pair, for example, 192.168.125.1 and 

192.168.135.1. These two addresses would correspond to a robot-OCU pair. The script then 

produced a configuration file for the VPN, which was virtually linked in the OS to point at the 

vpn.conf file. After a final reboot, router configuration was completed. 

4.2 PackBot Payload Design 

In order to test the functionality of the MANET, several different platforms required ad hoc 

nodes to be developed, including two robotic platforms. The first robotic platform discussed is 

the iRobot PackBot Explorer. 

The PackBot Explorer standard communications protocol is the IEEE 802.11g wireless standard. 

The platform is designed with a payload bay so that modular payloads can be easily integrated 

onto the robot. The payload interfaces to the robot through a proprietary 45-pin connector. This 

connector allows the payload to communicate with the robot computer through a variety of 

 7

The default IP address of the WRTSL54GS is 192.168.1.1 
8 

interfaces, including universal serial bus (USB) and Ethernet, and to draw 24-V DC power from 

the robot. 

In order to provide a weather-resistant payload, the COTS-based system had to be packaged. 

Because of time constraints, PackBot payload containers made from rapid prototyping plastic 

were used. Although the container was weatherized, the lightweight plastic was not ideal for a 

ruggedized system. However, since the payload bay sits within the frame of the robot, the 

payload receives a fair amount of protection from the robotic platform itself. 

Figure 3. PackBots showing ARL ad hoc payloads. 

In this design, the reconfigured Linksys router was removed from its plastic case and the antenna 

was removed. This was done so that the router could be repackaged into the payload sized 

container. Standoffs were used to mount the router board to the bottom of the payload container, 

to prevent the electronics from being jostled while the robot was in motion, and to position it 

above the bottom of the payload if moisture entered the container. 

The Linksys router required 12-V DC power, but the power provided by the robot is 24-V DC; 

therefore, the payload required the addition of a 24-12-V DC-DC converter. A PC-104 style 

DC-DC voltage converter was selected to accomplish this because of its small form factor. The 

voltage converter was mounted into the payload container below the footprint of the router 

board. 
9 

An antenna mount was then placed on the outside of the payload package to replace the standard 

router antenna, which had been removed to facilitate packaging. To minimize the loss of gain, 

the new antenna cable was soldered directly to the router board on one end and connected to the 

antenna via a single radio frequency (RF) connector on the other end. This design eliminated the 

need for multiple gain-reducing RF connectors between the board and the antenna. A high gain, 

flexible antenna originally in use on the PackBot was selected for the payload. This was to 

accommodate the operational capabilities of the PackBot, which include the ability to drive while 

inverted. 

Once all the payload components were designed and constructed, the payload hardware was 

integrated with the robot. A small integrated circuit board that provided 24-V DC power and 

Ethernet interfaces with the proprietary connector was added to the payload. Power was routed 

to the voltage converter and then connected to the router with a custom connector plugged into 

the existing DC power receptacle. Signal was sent directly between the Ethernet port on the 

breakout board and the Ethernet interface on the router via a standard Cat.5 cable. The final step 

was to re-configure the software and IP address of the PackBot so that it used the new ad hoc 

payload as its gateway. 

4.3 Gator Payload Design 

The second robotic platform that was modified was an iRobot/John Deere R-Gator. The R-Gator 

is a larger platform developed for transport and RSTA purposes. It is capable of being driven 

manually, tele-operated, or with semi-autonomous techniques such as waypoint following. The 

platform is multi-functional and can be used to transport people, supplies, or smaller robotic 

assets such as the PackBot Explorer. 

The R-Gator is designed with a large payload container that separates the passenger seats and 

cargo area in the rear of the robot. This container is used to house the electronics necessary to 

control the platform as a robotic asset. Since there was available space in this container, the 

COTS ad hoc node did not need to be housed in a separate weather-resistant and ruggedized 

housing. Instead, the router could be placed in the available free space. 

The R-Gator is equipped with two antennas, so a slightly different Linksys router (Model 

WRT54GS) was used. The selected router had two antenna input, making it capable of taking 

advantage of antenna diversity. Antenna diversity uses multiple antennas to use multi-path 

environments, thus improving performance and providing greater signal range. 

The robot had two available power points in the payload, one operating at 36-V DC unregulated 

and the second operating at 24-V DC regulated. However, like the previously integrated version 

of the Linksys router, this version also required an input of 12-V DC. To provide this, the 24-V 

DC power point was used, and a simple 24-12-V DC-DC converter was installed. Since the 

regulated 24-V line was not completely immune to slight variations in voltage level as other 

components in the robot were switched off and on, and the tolerance to power variations of the 
10 

router board was unknown, the necessary resistors and capacitors were soldered onto the power 

converter to ensure a stable 12-V DC output. 

Once the ad hoc node was powered, the signal needed to be connected to the computer systems. 

Unlike the PackBot, which has a single central processing unit, the R-Gator contains two 

computer systems. One handles robotic control, while the other handles image processing and 

geo-location via a compass and GPS unit. Each was connected into the router via an Ethernet 

connection and was given a unique IP address in the appropriate IP range in order for the router 

to serve as the gateway for both machines. 

4.4 Drop-off Node Design 

Preliminary testing indicated that the communications range of an ad hoc node was 

approximately 0.2 mile. In order to extend the range of the communications network to a 

suitable distance for field operations, as well as to allow assets to be controlled in NLOS 

situations, drop-off ad hoc nodes were added to the system. These nodes were needed to act as 

repeaters that could pass communications between multiple robot-OCU pairs. They needed to be 

capable of running for long periods of time without an external power source and be easily 

transportable so that they could quickly be emplaced and rearranged in the field as the conditions 

of the battlefield environment dictated. 

To solve the power problem, a 12-V DC battery pack, which is intended for use in portable DVD 

player applications, was chosen as a power source. The battery was lightweight and had a small 

form factor. Testing of the battery pack determined that it could provide power to an ad hoc 

node for as many as 12 hours, well beyond the power requirements of the drop-off node. 

To provide a fieldable drop-off node solution, the system had to be weather resistant and easily 

transportable. We accomplished this by packaging the node components in a small (10 x 8 x 

5 inches) Pelican case. The router board was secured to the bottom of the Pelican case with 

standoffs to prevent it from being damaged during transport. The battery was secured to the 

bottom of the case with industrial strength Velcro8 so that it could be held in place but could also 

be easily removed and replaced as needed. An AC adaptor was needed to charge the battery 

when the system was not fielded, and it was desired that the antenna be removable to limit 

potential damage during transport. Thus, the cases were designed to allow for enough space to 

store the AC adaptor and antenna so that a single drop-off node unit was completely selfsustaining. 

The stock Linksys router antenna was removed from the router unit so that it could be mounted 

inside the Pelican case. This was done to create a weather-resistant system and so that a 7-dB 

gain antenna could be added to the system. The higher gain antenna was chosen to increase the 

effective range of an individual node. In order to limit the loss between the antenna and the 

 8

Velcro is a registered trademark of Velcro USA, Inc. 
11 

board, care was taken to limit the number of connectors used, while the length of the antenna 

wire was kept to a minimum. Simultaneously, the design requirements necessitated that the wire 

be long enough to help the lid of the case to open easily so the system could be assembled and 

disassembled. A hole was drilled through the plastic router case lid so that no strain would be 

placed on the solder joint if the wire were pulled when the case was opened or closed. The RF 

connector selected was a reverse polarity TNC female connector, which mated with the chosen 

antenna. The need for this non-standard connector required that the wiring assembly be 

fabricated in house, instead of being purchased from a commercial site. 

Figure 4. Internals of ARL ad hoc drop-off node. 

Since the design of the drop-off module required the system to be easily transportable, it had an 

inherently small form factor. This was problematic since the closer the antenna is to the ground, 

the smaller the range of the node. During field testing, it was determined that the nodes could be 

strategically placed in trees, just above eye level. This placement was optimal for several 

reasons. The elevation gain allowed the nodes to operate above the dense scrub oak canopy in 

the test environment but below the tree canopy, giving us greater range and improved 

performance. Further, because the nodes were placed slightly above eye level, they were also 

more difficult to detect by the opposition force as they passed through the theater of operations. 
12 

4.5 OCU Node Design 

In order to control the robotic assets described, an OCU had to be designed and developed. The 

OCU had to be lightweight, easy to carry, and ruggedized to protect it from the abuses of 

dismounted field operations. To accomplish this, a ruggedized tablet PC was selected to provide 

processing capabilities. The tablet was mounted onto a custom designed metal frame that housed 

two joysticks for robotic control. The joysticks were connected to the tablet through the USB 

port. A neck strap was connected to the frame to make the unit easier to carry. The router was 

mounted to the back of the frame so that everything was connected as a stand-alone system. 

The OCU needed to be able to talk on two different networks in order to accomplish its two 

primary functions: 

• Command and control of a designated robotic asset; 

• Communication “uplink” to higher echelons in order to forward SA media (video and 

images) being collected by the robotic platform. 

This need for simultaneous communications on two networks required the system to have two 

network interface cards (NICs). The tablet PC selected in the design phase for this project only 

had one on-board NIC, so a second was added to the system with the use of a PCMCIA9 card. 

The internal routing table on the tablet PC was configured to ensure that traffic destined for the 

robotic platform always passed through the PCMCIA card, which was connected to the ad hoc 

router. All other network traffic was routed through the native NIC, which was connected to a 

Soldier Radio Waveform (SRW) radio that passed data to platoon-level vehicles for 

dissemination to ground forces. This allowed both devices to communicate with their respective 

networks without interfering with one another. 

Since the router was mounted onto the frame of the OCU, power could be provided from the 

battery source providing power to the tablet. The tablet required an input of 20-V DC, while the 

router only needed 12-V DC, but a battery cable was designed to provide both of the necessary 

voltages to the devices. After testing, it was determined that the cable design was correctly 

providing the required voltages, but the requirements were causing the battery to be drained 

unevenly. Therefore, an independent battery for the router was added to the system, increasing 

router run time but increasing the weight of the system 3.15 lb to 14.05 lb. 

 9

PCMCIA is personal computer memory card international association (now called PC cards). 
13 

Figure 5. ARL OCU showing ad hoc node. 

5. Test and Analysis 

Seven evaluations of the mobile ad hoc system were performed over a 4-month period from May 

until August in the summer of 2006. The purpose of the evaluations was to obtain some absolute 

performance metrics (maximum range, allowable video rate) as well as more qualitative metrics 

relating to the system’s ability in various environments and suitability for certain types of 

operations. 

Although the final experiment took place at Fort Dix, not all the evaluations were performed on 

site. Equipment was shipped to Fort Dix incrementally throughout the summer as it became 

ready for use. Consequently, engineers only spent a week or two at a time on site with the 

equipment, which mandated further testing and development at Adelphi Laboratory Center 

(ALC). Thus, improvements were often made in equipment before shipping as a result of the 

evaluations at Fort Dix. 

For the C4ISR OTM experiment, the MANET was designed to provide a robust and extendable 

ad hoc network. Its primary application was to provide for tele-operation of the CISD robotic 

assets. This mode of operation allows the user to remotely control the robotic platform using 
14 

only streaming video displayed on the OCU. It had been previously determined that the 

minimum frame rate required to support tele-operation was approximately seven frames per 

second10. Thus, one of the quantitative measurements was the video frame rate that the network 

could support in various conditions. The streaming video from the cameras on the robotic 

platforms was compressed before transmission with the Motion-JPEG compression scheme. The 

CISD-designed underlying network architecture, known as CIPNet11, breaks the stream into 

packets to be sent over the wireless network. On the OCU side, the video stream is displayed by 

CISD’s command and control application, CollectControl. This Windows12-based application 

allows the user to select which asset s/he would like to view and/or control and to control the 

resolution of the video source and its frame rate. 

Figure 6. ARL OCU showing operation of CollectControl. 

For the exercise, a VPN was established between each robot and OCU pair. This was requested 

by the C4ISR OTM architects and limited the actual ad hoc operation of the network. However, 

this VPN did not affect the ability of network traffic to hop between end nodes via the drop-off 

nodes. It was designed so that all robot-OCU pairs could use any given drop-off nodes as 

 10French et al., “Modes of Control of an Unmanned Ground Vehicle (UGV)”, presented at the ARL Collaborative 

Technology Alliance (CTA) Symposium as part of the Advanced Decision Architectures (ADA) CTA, 2003. 

11Choy, S. “CIP Network Agent Service API User’s Guide” ARL, Adelphi, MD, February 2001. 

12Windows is a trademark of Microsoft Corporation. 
15 

hopping points, since the drop-off nodes were not subject to the VPN limitations. Instead, they 

just passed all traffic and let the end nodes do the VPN administration. 

5.1 Initial Robotic Field Test (Fort Dix, New Jersey) 

Because of the short developmental schedule, no rigorous testing had been accomplished by 

CISD before the delivery of the robotic systems on site at Fort Dix. They were confirmed to be 

operational, but no range, performance, or other tests were performed before five systems were 

shipped. 

System evaluation was performed on Range 47 at Fort Dix. The test was performed on 4 May 

2006 under sunny skies. The test site was a large, mostly flat, rectangular field with a few 

rolling hills and a dirt road bisecting its area down the middle. There were no trees in the range, 

but the range was covered by areas of scrub brush and sand. Also present were a number of 

training dummies and vehicles, since the site also served as night vision training for Soldiers 

stationed at Fort Dix. 

Figure 7. Initial robotic field test site at Fort Dix, New Jersey. 

5.1.1 Objectives 

The objectives of this test were straightforward. First, we wanted to determine how far our new 

ad hoc communications network between the OCU and robot could acceptably operate a robotic 

asset. Secondly, we hoped to determine the additional communications range that an ad hoc 
16 

drop-off node emplaced between the OCU and robot would provide, as well as how the network 

performed when multiple drop-off nodes were emplaced. Finally, we wanted to determine the 

effect the VPN had on operational range and video performance. 

5.1.2 Results 

The distances listed in table 1 reflect the point at which driving the vehicle via the OCU video 

became impossible because of increasingly erratic control capabilities and laggy or bursty video. 

In most cases, the ad hoc network maintained connection, but data transmission delays prevented 

timely control. When used, the drop-off nodes were positioned on the ground on a berm 

approximately 0.3 m above the road level or on cinder blocks set on the berm, approximately 

0.75 m above the road level. 

Table 1. Results of initial robotic field test. 

Distance Test 

Performed 

Number of 

Drop-Off 

Nodes 

Height of Drop-Off 

Nodes 

Location of DropOff Nodes VPN Result 

OCU to PackBot 0 N/A N/A Yes 193 m 

OCU to PackBot 1 0.3 m 160 m Yes 321 m 

OCU to PackBot 1 0.75 m 160 m Yes 418 m 

OCU to PackBot 1 0.75 m 160 m No 434 m 

OCU to PackBot 2 0.75 m, 0.3 m 160 m, 354 m Yes 434 m 

OCU to R-Gator 0 N/A N/A Yes 418 m 

OCU to R-Gator 1 0.3 m 321 m Yes 692 m 

5.1.3 Discussion 

Generally, the ad hoc communications system worked better than was anticipated and much 

better than the previous generation “black box” ad hoc nodes. Not only were they packaged in a 

significantly smaller form factor, but the software appeared more robust, working every time it 

was powered on. 

The first noteworthy result of these tests was the distance at which we were able to control the 

robots. The old “black box” version of ad hoc nodes allowed operation of a robotic platform at 

distances rarely greater than 100 m. With the new system, we were consistently obtaining 2 to 4 

times greater distance from the OCU to a robot—a significant improvement. In all cases, the 

video was viewed in CollectControl at a rate greater than 10 frames per second until the robots 

became un-drivable, at which point, the frame rate dropped significantly. 

The most difficult problem we had was with the video becoming bursty at lower frame rates (less 

than 10 frames/second) as the robot to OCU distance increased. The operator observed the video 

smoothly streaming, when a slight pause where the video seemed to stop, followed by a large 

number of old video frames being displayed rapidly. Many times, the robot was correctly 

executing the commands sent by the operator, but the video displayed on the OCU did not 
17 

correctly reflect the robot executing the commands. On some occasions, both the control 

commands on the robot side and the video on the OCU side seemed to queue up and then burst 

out. The effect was the robot briefly driving itself after the operator had stopped moving the 

joystick. This is an important safety issue that needs to be studied further. Preliminary 

discussions led us to suspect the VPN as the culprit. However, when the VPN was removed, we 

observed the same behavior. Additional research needs to be performed in order to isolate the 

cause of this problem. 

CollectControl had two further issues. The first is the issue of a platform “commandeering” 

driving control from the operator. This is a known issue where CollectControl de-selecting the 

“driving” button while an operator is controlling a robot at seemingly random intervals, causing 

the robot to stop moving. This is obviously an issue that needs to be resolved, since losing 

control of a robot when no other issues are at play (i.e., communications problems) is 

unacceptable. The second issue is that CollectControl de-selects the “driving” button when the 

ad hoc network experiences a slight drop-out. This is technically the correct functionality. 

However, the ad hoc network infrequently experiences drop-outs that occur momentarily for no 

apparent reason, and it regains a strong connection immediately afterward. Further investigation 

is needed to find a solution that prevents CollectControl from losing control during short 

interruptions in network connectivity. 

As mentioned before, the VPN software on the ad hoc nodes was originally targeted as a possible 

cause of the bursty video performance. While the removal of the VPN software was found not to 

be the cause of the problematic video performance, it did have an effect on the network. 

Removing the VPN software reduced reconnect time, following one of the nodes being powered 

off, from approximately 3 to 4 minutes to approximately 30 seconds. The engineers in CI-CN 

will be investigating a permanent solution to reduce the reconnect time, with or without the VPN 

software running. 

The tests showed us the importance of antenna configuration in communicating with the robots. 

On the drop-off ad hoc nodes, we noticed a substantial improvement in range just by moving the 

node from the ground to on top of an upright cinder block, a height increase of only about 

0.45 m. Replacing the stock antennas on the drop-off nodes with longer antennas with a higher 

gain (and more flexibility for practical reasons) could yield better performance. Similarly, the 

R-Gator has two diversity antennas positioned more than 1.8 m off the ground. As the tests 

showed, with communication payloads operating identical software, the range of the R-Gators 

was greatly increased over PackBot performance. This replicated the results obtained by the 

CI-CN when diversity antennas were used in their own ad hoc network tests before the nodes 

were delivered. The stock internal PackBot communications also use a two-antenna diversity 

configuration, which was disabled for these tests. It would be worthwhile to investigate the use 

of the existing PackBot antennas with our payload or modifying the payload to also use the 

diverse configuration. 
18 

5.2 Informal Robotic Field Test (Adelphi Laboratory Center) 

This was an informal test performed quickly to determine if a recently constructed ad hoc 

communications payload for a PackBot was operational. It was performed at the ALC on 

25 May 2006 on a dead-end road leading to the back gate of the post. The road is paved with a 

gentle downhill slope and a “dog-leg” to the right. There is heavy forest cover on either side of 

the road. 

5.2.1 Objectives 

Since we had some extra time following the initial operational check of the payload, we decided 

to also test the operation of the ad hoc network in a multi-hop configuration in a slightly different 

manner than our multi-hop test at Fort Dix. In addition, we wanted to attempt an NLOS test, and 

the inclusion of multiple hops through ad hoc drop-off nodes allowed us to test the network 

performance as the road made a near 90-degree right-hand turn and the robot moved out of the 

line of sight. 

Here, we chose to place the drop-off nodes at about 75% of the maximum one-hop distance for 

each hop. That is, we planned to drive the PackBot until network failure and then placed the 

next ad hoc node at roughly 75% of that distance. This was repeated for each hop until we ran 

out of drop-off nodes and/or the network failed. Each hop was one of the following: OCU to 

robot, ad hoc node to ad hoc node, and ad hoc node to robot. For this test, the VPN was turned 

off for all ad hoc nodes. 

5.2.2 Results 

The network successfully routed control and video to the OCU at a modest frame rate of 7 

frames per second and resolution of 320x240 through two drop-off nodes. The total distance 

traversed was 483 m. The hop from the second drop-off node to the robot was around the 

90-degree bend in the road, creating an NLOS situation between the robot and the OCU. 

5.2.3 Discussion 

This was an informal test to ensure the payload was working. It is being included in this 

document solely for the sake of complete disclosure. 

The network operated as anticipated. However, we noticed one issue involving network routing 

latency. When the robot reached the “end” of the network, we placed an ad hoc drop-off node at 

approximately 75% of that distance, as described. Leaving the robot where it failed, one would 

expect that the robot would regain connectivity following the power-up of the newly placed 

drop-off node. However, it tended to take 2 to 3 minutes for the network to discover that it could 

route through this new ad hoc node. Thus, there was a noticeable delay after the drop-off node 

was powered on before video and control of the robot were regained by the OCU. This is 

currently being investigated by CI-CN and will be re-evaluated further in the next formal round 

of testing. 
19 

5.3 Formal Robotic Field Test (Adelphi Laboratory Center) 

Before to leaving for Fort Dix for the formal UGV evaluation, we wanted to do additional 

performance testing on the robotic control network in different configurations, as well as fully 

test the PackBot payloads with their new antennas, added per the results of a previous test (initial 

robotic field test)13. The tests were performed at ALC on 1 June 2006 in the parking lot next to 

and on the roads surrounding the Harry Diamond buildings, as well as in a wooded area between 

CISD’s tents and the path on the western edge of the installation. 

5.3.1 Objectives 

The goal of these evaluations was to do more rigorous testing on the robot-OCU pair to 

determine how the ad hoc network responded to non-standard configurations that had not yet 

been evaluated. The first objective was to determine the distance over which the ad hoc 

communications system could acceptably operate a robotic asset using multiple hops through ad 

hoc drop-off nodes. Next, we determined the performance of the ad hoc network in NLOS 

applications using multiple ad hoc drop-off nodes. This included determining the feasibility and 

performance of the ad hoc network in a “mesh” configuration (i.e., blanketing a large area with 

multiple drop-off nodes). We also hoped to determine the performance of the ad hoc network 

over multiple hops when a robotic platform (PackBot, R-Gator) rather than an ad hoc drop-off 

node acted as an ad hoc relay node. Finally, we wanted to determine the performance of the ad 

hoc network in heavily wooded environments. These tests were performed with the VPN turned 

off because of configuration limitations. 

Because this evaluation was in preparation for the formal UGV evaluation taking place at Fort 

Dix, we hoped to mimic some of the evaluations that the C4ISR OTM evaluators would be 

performing on our robots, such as target detection distance and target classification14. 

5.3.2 Results 

In performing the NLOS test, we attempted to drive a PackBot all the way around the Harry 

Diamond building complex at ALC. Ad hoc drop-off nodes were placed on curbs at the four 

corners of the complex. When possible, they were placed on something that raised their heights 

by a small amount (less than 3 feet). The OCU was situated on a small cart on the sidewalk 

adjacent to the east side of the complex. The PackBot was driven in a counter-clockwise 

direction around the buildings. Connection was not established between all the drop-off nodes at 

the onset of the test. The PackBot was successfully driven down the front side of the building to 

the second closest drop-off node. However, that drop-off node could not make a connection with 

the next drop-off node. Our hope was that the PackBot would act as a relay between the two 

nodes as it moved between them. However, because of the elevation change between the two 

 13Although the PackBot tested in the initial robotic field test had the new antenna, the remaining PackBot communications 

payloads still had a different, rigid antenna installed. This test confirmed operation of the antennas added to the remaining 

PackBots. 

14Jennings, R., “UGV Evaluation” Mitre Corp. 
20 

nodes on the far side of the building, communications failed. The PackBot reached just over half 

way around the building complex. Attempts were made during the test to increase the height of 

the drop-off nodes suffering from lack of connectivity in hopes of creating a network connection. 

In certain cases, a link was created as a result of this but would only increase the controllable 

distance of the robot for a few feet before the link was broken again. Several changes were made 

in the ad hoc node software during the experiment in attempts to mitigate these issues. These 

included increasing the time tolerance in an effort to increase the distance at which the robot was 

able to be controlled and to decrease the beacon time. Neither of these changes resulted in 

substantial improvements in connectivity or performance. 

For the mesh connectivity test, ad hoc drop-off nodes were placed at the four corners of the main 

parking lot adjacent to building 202 at ALC. The OCU was kept in the same location on the east 

side of the building. We used the CI-CN ad hoc connectivity visualization software to visualize 

connections and their strength between all ad hoc nodes. This diagnostic software indicated that 

all the ad hoc nodes had connections to every other ad hoc node immediately after all the devices 

were powered up. The robot was driven across the parking lot with no loss of connection or 

reduction in video quality. 

Evaluating the robots in the wooded area proved to be pertinent to the environment the robots 

would be operating in at Fort Dix. We had not been able to communicate, using the old ad hoc 

communications systems, through a heavily wooded area approximately 150 m in extent. This 

test was to stand at a clearing on one side of the woods with the OCU and attempt to drive the 

PackBot through this 150-m woods with no ad hoc drop-off nodes. If the robot could not be 

controlled the whole distance, an ad hoc drop-off node would be placed part way. 

While performing the test in a heavily wooded area, we drove the PackBot into a large downed 

tree branch which punctured the ad hoc payload. Upon the PackBot’s encounter with the branch, 

the power to the payload was interrupted. Since we were unable to regain communications with 

the robot, testing was suspended for the day, since our only ad hoc payload had been damaged 

(the others were on site at Fort Dix). We learned that the branch had merely knocked loose one 

of the power wires in the payload, which suffered no significant internal damage. 

Thus, not all of the objectives were achieved, for two reasons. First, the recently constructed ad 

hoc drop-off nodes requiring testing were not completed in time, mainly because of procurement 

delays. Secondly, the ad hoc payload on our test PackBot was rendered temporarily inoperable 

by the aforementioned tree branch while we were performing the wooded area testing. 

5.3.3 Discussion 

There are a number of issues that we believe to have contributed to the failure of the NLOS test. 

Most notably, the elevation changes around the building affected the performance of the 

network. Because the PackBot and the ad hoc drop-off nodes operate very low to the ground, 

many times there is no line of sight connection between nodes even over very small rises. 
21 

Although this does not often sever the link created, it can significantly decrease the signal 

strength, causing a drop in available video frame rate, which greatly affects the user’s ability to 

drive a robot. 

Through monitoring the network visualization software, we observed some “oscillation” between 

which nodes the robot would route through when in view of two nodes. The delay in packet 

forwarding as routes switched between nodes caused a noticeable lag in the video display in 

CollectControl, making it difficult to control the robot. We hypothesized that this was caused 

because the VPN was turned off. However, we were not able to verify that claim during this test. 

The initial mesh connectivity test was inconclusive. In short, the network performed too well. 

We had hoped to see the robot moving across the parking lot and connecting to the closest 

node(s) as appropriate, but instead, we saw the robot connect to all the nodes at once. We clearly 

need to perform this test in a larger area or perhaps in more diverse terrain (wooded, hilly) to be 

able to observe varying behavior. 

5.4 Preliminary UGV Evaluation (Fort Dix, New Jersey) 

Because the C4ISR OTM program managers wrote their UGV evaluation, based on a lesscapable UGV platform that was used in the experiment the previous year, they thought it 

advantageous for us show them some capabilities of the robotic systems and the ad hoc network 

before the formal UGV evaluation. We used this as an opportunity to perform more tests and to 

observe the behavior of the network in the field. The evaluation was performed on Tactical 

Range 9D at Fort Dix on 6 June 2006 under overcast conditions. 

5.4.1 Objectives 

The test we devised was to drive on the dirt trails in the heavily wooded area from a clearing. 

The robot was driven until control was lost, then an ad hoc drop-off node was emplaced, control 

regained, and the operator continued to drive the robot until the procedure stopped working. 

Given the environment, this allowed us to simultaneously evaluate the network performance in 

NLOS, wooded, hilly, and non-urban environments. 

5.4.2 Results 

We drove the PackBot down a canyon-like trail that sloped away from the OCU until we lost 

control. We then placed ad hoc drop-off nodes in line of sight from the OCU to the drop-off to 

the robot at the highest location we could using the terrain. The original plan was to use one or 

two drop-off nodes to get through the trail to a clearing where a target HWMMV was located, 

and take a picture of it in CollectControl. We accomplished that easily using only one drop-off 

node, so we continued adding nodes to the network and drove the PackBot farther away from the 

OCU. After adding a second node, we were able to drive it so far that it took us nearly 

10 minutes to locate the robot, as when driving the operator was simply driving toward open, 

sandy areas, with no concern for where the robot was on the map. It is very easy to get 
22 

disorientated when tele-operating the robot in this manner. Although the robot appeared in its 

correct location on the mapping system, limitations in map resolution and the hilly, wooded 

terrain made it difficult to locate. After finding the robot, we were able to drive through 3 and 4 

nodes before we decided to stop when control was becoming questionable. Control became 

more bursty with the video freezing and suddenly displaying all frames as control was routed 

through more network hops and the distance between nodes increased. No formal distances were 

measured in this evaluation, but they were comparable to those obtained in the first Fort Dix 

field test at the beginning of May. 

5.4.3 Discussion 

This evaluation was considered a success, as it demonstrated to the program managers that our 

robotic system was more than capable of providing a wide range of possible operating scenarios. 

As seen in previous tests, there were times when the network was approaching its maximum 

working distance and connectivity temporarily dropped out, causing CollectControl to release 

control of the robot, even though it immediately had a strong frame rate following the glitch. As 

noted elsewhere, this behavior is the result of a conscience decision made for safety concerns. 

We also observed that video from the PackBot was limited to frame rates of three to four frames 

per second at very close distances to the OCU (less than 3 m). This is the result of deliberate 

tuning of the ad hoc routers performed during this evaluation, allowing for greater control 

distance at the expense of throughput at short ranges. In most operating scenarios, this is not an 

issue. 

5.5 UGV Evaluation (Fort Dix, New Jersey) 

Researchers from HRED were present at the evaluation to gather human factors data on the 

human operator-PackBot system interaction. We anticipated an excellent outcome of this test 

since the PackBot was designed to operate in urban environments rather than the heavily wooded 

environments it had encountered thus far. The evaluation was performed at the Time Square 

military operations in urban terrain (MOUT) site at Fort Dix on 8 June 2006. This MOUT site 

consisted of a number of dirt streets lined with buildings made of large, metal shipping 

containers. The buildings contained various furnishings, such as tables, chairs, and mannequins 

representing civilians. Many buildings were two stories and had interior or exterior staircases. 

Also present at the site were numerous cars parked on the sides of the roads. One road continued 

past the MOUT site, as if heading to the suburbs and provided +0.25 mile of straight, flat road. 

5.5.1 Objectives 

The primary objective of the evaluation was to demonstrate the capabilities of our robotic system 

in an urban environment. This included how well the ad hoc network functioned in an 

environment full of reflective metal surfaces and obstructed views. Although unrelated to 
23 

network performance, we also hoped to show the urban environment capabilities of the PackBot, 

such as stair climbing and operation in the dark. 

5.5.2 Results 

The first test we ran was a straight line distance test. Although similar tests had been performed 

on uneven terrain, this test offered a very flat, straight stretch of dirt road on which to test. In 

addition to taking advantage of the road, we thought it would be interesting to see if the alley at 

the beginning of the road, through which the robot would pass, would challenge the network. 

Standing at the entrance to the MOUT site at the beginning of the dirt road, we were able to 

operate the PackBot and R-Gator as far as 386 m and 402 m, respectively. These distances were 

actually better than our initial straight line testing performed in June. Although we lost the 

ability to control the PackBot at that distance, the R-Gator still had a good connection but was at 

the end of the road. 

The next test was evaluating the NLOS performance in the urban environment. The goal was to 

drive the robotic platforms all the way around the triangular city block at the MOUT site. We 

hypothesized that on the far side of the block, the significant amount of metal buildings would 

most likely severely affect the network. With the operator inside one of the metal buildings, the 

connection was lost and drop-off nodes were placed at the corners of the block. This allowed 

continued successful driving of the PackBot, with the OCU maintaining a reasonable frame rate 

and good control of the robot the rest of the way around the block. With the operator standing at 

the entrance to the MOUT site, the PackBot was able to be driven all the way around the block 

without the use of the drop-off nodes. The R-Gator was able to drive half way around the block 

during its test, going just out of sight around the corner. However, at that point, a mechanical 

failure on the R-Gator resulted in it having to be withdrawn from the test. 

The final test required an operator to clear a two-story building from a concealed location in a 

building across that street. Of interest was whether a tele-operated robotic search could be 

completed with an acceptable level of thoroughness and in a timely manner. The operator sat in 

a chair away from windows on the ground level of one of the buildings along a road in the 

MOUT site. The robot was placed at the entrance to a different building across the street. Using 

only the OCU, the operator then attempted to clear the building, which involved checking all 

rooms on both levels for civilians (mannequins) and, if detected, taking imagery of the civilians. 

This would test the ad hoc communication network’s ability to operate between two metal 

buildings in an urban environment and the effectiveness of using a UGV for this type of 

reconnaissance. The test was performed four times in buildings of various configurations. The 

system demonstrated good utility in this exercise, clearing a two-story building, including going 

up and down stairs in the dark, in 10 minutes. Overall, the operator was able to correctly identify 

88% of the civilians in a building, with the PackBot having some trouble finding targets that 

were not easily apparent from its low vantage point. However, had the operator taken more time 
24 

in each room to maneuver the PackBot camera arm, the probability of detection may have 

improved. 

Figure 8. PackBot operating at MOUT site. 

5.5.3 Discussion 

The main issue we expected to see in this evaluation was network degradation caused by 

buildings, since metal tends to reflect wireless signals in unpredictable ways, causing severe 

multi-path interference issues. However, these effects were largely unnoticed. In the straight 

line distance test, we observed much better distances than we did in an open field. This may 

have been attributable to the ground being flatter than at the initial test site, but the fact remains 

that the buildings did not contribute negatively to the performance of the network. Similarly, 

when attempting the building-clearing behavior, we expected the network to become 

questionable as soon as the robot entered its objective building. Again, however, the network 

performed well, with strong connectivity throughout the building. The only time anticipated 

network problems actually occurred was when we drove the robot around the block. We 

expected the connection to drop on the far side of the block, since there was a large amount of 

structure between the OCU and robot. As expected, the connection dropped when the operator 

was located indoors. However, the network regained its previous performance when the ad hoc 

drop-off nodes were placed in the intersections on the corners of the block and never lost a level 

of performance when the operator was outdoors. We had expected to see more interference 
25 

issues related to the large amount of sheet metal at the MOUT site but were encouraged when 

that did not occur. 

5.6 C4ISR On-The-Move Experiment (Fort Dix, New Jersey) 

All this testing and evaluation was in preparation for three weeks (10 July 2006 to 28 July 2006) 

of experimentation to be performed by trained United States National Guard Soldiers. 

Throughout the three-week period, varying sets of technology were combined and given to the 

Soldiers for use in mock operational scenarios. The goal was to determine how well the future 

technologies might improve the Soldier’s SA, at dismounted and higher echelons. 

The actual “experiment” was really a demonstration, since experimentation with the systems had 

already taken place. No changes were made in the network over the course of the three weeks, 

and it performed as we had anticipated. In fact, the biggest problem with the robotic control 

system had nothing to do with the technology itself but in getting the Soldiers to use the 

technology. There was some frustration among CISD folk regarding how and how much our 

equipment was used by the Soldiers in the field. CISD engineers provided adequate training 

before the experiment to familiarize the Soldiers with the capabilities and controls of the 

unmanned systems. However, this is indicative of a larger Army doctrine issue relating to the 

use of unmanned systems, not issues with the technology itself. 

Two technology related issues did present themselves during the experiment. The first was an 

issue of communicating in very dense forest locations on a few occasions. It was reported to us 

that when a Soldier was attempting to drive a PackBot from a prone position in deep wooded 

cover, the operational range was reduced to approximately 9 m. Although there are possible 

physical limitations of the system at play here, with the antennas on the OCU and PackBot being 

very close to the ground and severely obstructed paths limiting connectivity, the result was 

surprising. This poor level of network performance had not been exhibited during any of the 

previous tests. Because of experimental design constraints, we were not able to observe or 

troubleshoot this issue in the field during the exercise as it occurred. 

The second issue was specific to the R-Gator. CISD added a high-powered camera to the RGator platform, a DI-5000 made by Digital Infrared Imaging, Inc. When the DI-5000 was 

pointed at a visually complex scene, such as a very densely wooded environment at close range, 

the packets that the Motion-JPEG video compression scheme created were very large. It was 

observed that when the camera was pointed toward such scenes, the ad hoc network did not 

forward the packets at a resolution of 320x240, the default CollectControl resolution. This was 

confirmed when a lower resolution (160x120) was specified; lower quality video containing 

smaller packets streamed over the ad hoc network. As a workaround, the Motion-JPEG 

compression level for the DI-5000 was increased. This resulted in smaller video packets that did 

not cause problems on the ad hoc network; however, the higher compression level substantially 

decreased the quality of the image. Both of these issues will be further examined at ALC. 
26 

6. Conclusion and Future Work 

As a whole, ARL’s involvement in the C4ISR OTM experiment was a success. The MANET 

and robotic platforms performed admirably with minimal issues throughout the summer, often 

enduring 100 °F and high humidity. However, as noted, there are three issues that need to be 

further investigated (bursty video, the large packet issue, and reduced network performance in 

heavily wooded areas). The likely candidates in the bursty video issue are the ad hoc routing 

protocol and CollectControl. The ad hoc software will be examined to determine if it is queuing 

the video frames, and CollectControl will be studied to possibly include an algorithm to discard 

old video frames so they are not displayed. The solution to this issue could impact the resolution 

of the other two. There is a test plan in place for further investigation of these issues, and it will 

be conducted as time and manpower allow. 

Work will continue on the operation and evaluation of this network in true ad hoc fashion, 

without the VPN activated. Although its application in this experiment (as an end-to-end 

network with the ability to use any drop-off node) had its advantages, the true benefit of an ad 

hoc network lies in its ability to connect a large group of mobile nodes. As such, provided that 

higher level network architecture does not prevent it, the network will be implemented as a true 

MANET. 

After watching Soldiers use the ad hoc drop-off nodes in a field environment, we observed that 

they often had difficulty emplacing the nodes in locations that would improve network 

connection and/or performance. It could be beneficial to include a utility for visualizing network 

strength and connectivity on the OCU, aiding the Soldiers in intelligently placing the nodes. 

Such a piece of software exists in CI-CN, but it does not easily lend itself to integration into an 

OCU-user interface. Further investigation into how best represent this information to the user 

will occur in the future. 

Ongoing research into quality of service and intrusion detection for MANETs is being performed 

at ARL. It is hoped that these research areas will lead to more secure and robust ad hoc networks 

and could be implemented on the MANET discussed in this document. 

Finally, as the robotic platforms that are controlled in an ad hoc network become smaller and 

more constrained, the packaging for the COTS wireless routers running the ad hoc software will 

need to be examined. Presently, the COTS pieces were used “as is,” being strapped to the back 

of the OCU or inserted into large payload containers on the mobile platform. As the platforms 

shrink, so does their ability to carry large, modular payloads. A highly integrated approach to 

developing the communications hardware may need to be investigated. 
27 

Distribution List

ADMNSTR 

DEFNS TECHL INFO CTR 

ATTN DTIC-OCP (ELECTRONIC COPY) 

8725 JOHN J KINGMAN RD STE 0944 

FT BELVOIR VA 22060-6218 

DARPA 

ATTN IXO S WELBY 

3701 N FAIRFAX DR 

ARLINGTON VA 22203-1714 

OFC OF THE SECY OF DEFNS 

ATTN ODDRE (R&AT) 

THE PENTAGON 

WASHINGTON DC 20301-3080 

US ARMY TRADOC 

BATTLE LAB INTEGRATION & TECHL 

DIRCTRT 

ATTN ATCD-B 

10 WHISTLER LANE 

FT MONROE VA 23651-5850 

PM-FCS (BCT) TECHNOLOGIES 

ATTN M/S CV-52 S YOUNG (2 COPIES) 

7990 SCIENCE APPLICATIONS CT 

VIENNA VA 22182 

SMC/GPA 

2420 VELA WAY STE 1866 

EL SEGUNDO CA 90245-4659 

COMMANDING GENERAL 

US ARMY AVN & MIS CMND 

ATTN AMSAM-RD W C MCCORKLE 

REDSTONE ARSENAL AL 35898-5000 

US ARMY INFO SYS ENGRG CMND 

ATTN AMSEL-IE-TD F JENIA 

FT HUACHUCA AZ 85613-5300 

US ARMY SIMULATION TRAIN & 

INSTRMNTN CMND 

ATTN AMSTI-CG M MACEDONIA 

12350 RESEARCH PARKWAY 

ORLANDO FL 32826-3726 

US GOVERNMENT PRINT OFF 

DEPOSITORY RECEIVING SECTION 

ATTN MAIL STOP IDAD J TATE 

732 NORTH CAPITOL ST., NW 

WASHINGTON DC 20402 

US ARMY RSRCH LAB 

ATTN AMSRD-ARL-CI-OK-TP 

 TECHL LIB T LANDFRIED (2 COPIES) 

BLDG 4600 

ABERDEEN PROVING GROUND MD 21005-5066 

US ARMY RSRCH LAB 

ATTN AMSRD-ARL-CI J GOWENS 

ATTN AMSRD-ARL-CI-C B BROOME 

ATTN AMSRD-ARL-CI-CB B 

 O'BRIEN (3 COPIES) 

ATTN AMSRD-ARL-CI-CB C WINSLOW 

ATTN AMSRD-ARL-CI-CB D 

 BARAN (3 COPIES) 

ATTN AMSRD-ARL-CI-CB H NGUYEN 

ATTN AMSRD-ARL-CI-CB J KOVACH 

ATTN AMSRD-ARL-CI-CB L TOKARCIK 

ATTN AMSRD-ARL-CI-CB N FUNG 

ATTN AMSRD-ARL-CI-CB R GREGORY 

ATTN AMSRD-ARL-CI-CB T GREGORY 

ATTN AMSRD-ARL-CI-CN B LUU (3 COPIES) 

ATTN AMSRD-ARL-CI-CN B SADLER 

ATTN AMSRD-ARL-CI-CN G RACINE 

ATTN AMSRD-ARL-CI-CN P BUDULAS 

ATTN AMSRD-ARL-CI-CN R GOPAUL 

ATTN AMSRD-ARL-CI-CN R HARDY 

ATTN AMSRD-ARL-CI-OK-T 

 TECHL PUB ( 2 COPIES) 

ATTN AMSRD-ARL-CI-OK-TL 

 TECHL LIB (2 COPIES) 

ATTN AMSRD-ARL-D J M MILLER 

ATTN AMSRD-ARL-SE-SS J HOUSER 

ATTN AMSRD-ARL-SE-SS L ZONG 

ATTN IMNE-ALC-IMS 

 MAIL & RECORDS MGMT 

ADELPHI MD 20783-1197
28 

INTENTIONALLY LEFT BLANK