UGS, UGV, and MAV in the 2007 

C4ISR OTM Experiment 

by Timothy G. Gregory, Jesse B. Kovach, 

Robert P. Winkler, and Christopher H. Winslow 

ARL-TR-4419 April 2008 

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-4419 April 2008 

UGS, UGV, and MAV in the 2007 C4ISR OTM Experiment 

Timothy G. Gregory, Jesse B. Kovach, 

Robert P. Winkler, and Christopher H. Winslow 

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)

April 2008 

2. REPORT TYPE 

Final 

3. DATES COVERED (From - To) 

May to August 2007 

5a. CONTRACT NUMBER 

5b. GRANT NUMBER 

4. TITLE AND SUBTITLE 

UGS, UGV, and MAV in the 2007 C4ISR OTM Experiment 

5c. PROGRAM ELEMENT NUMBER 

5d. PROJECT NUMBER 

5e. TASK NUMBER 

6. AUTHOR(S) 

Timothy G. Gregory, Jesse B. Kovach, Robert P. Winkler, and 

Christopher H. Winslow 

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-1128 

8. PERFORMING ORGANIZATION 

 REPORT NUMBER 

ARL-TR-4419 

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 unlimited. 

13. SUPPLEMENTARY NOTES 

14. ABSTRACT 

In the summer of 2007 as part of the Command, Control, Communications, Computers, Intelligence, Surveillance, and 

Reconnaissance On-the-Move (C4ISR OTM) experiment, the Army Research Laboratory (ARL) and the CommunicationsElectronics Research, Development, and Engineering Command (CERDEC) demonstrated the viability of integrating a variety 

of unattended ground sensors (UGS), unmanned ground vehicles (UGVs), and micro air vehicles (MAVs) into a Force XXI 

Battle Command Brigade and Below (FBCB2) based system that provides situational awareness (SA) and command and control 

(C2) to the lowest tactical echelons. In this report we describe the system architecture, techniques and components used to 

effect this integration. 

15. SUBJECT TERMS

UGS, UGV, MAV, C4ISR, SA 

16. Security Classification of: 

19a. NAME OF RESPONSIBLE PERSON

Christopher H. Winslow 

a. REPORT 

U 

b. ABSTRACT 

U 

c. THIS PAGE 

U 

17. LIMITATION

OF 

ABSTRACT 

U

18. NUMBER 

OF 

PAGES 

36

19b. TELEPHONE NUMBER (Include area code) 

(301) 394-5617 

Standard Form 298 (Rev. 8/98) 

Prescribed by ANSI Std. Z39.18 
iii

Contents 

List of Figures iv

1. Introduction 1

2. Software Infrastructure 2

2.1 The Agile Computing Middleware..................................................................................2 

2.1.1 The Existing System............................................................................................2 

2.1.2 Future Work, The ACM ......................................................................................5 

2.2 The Servers......................................................................................................................5 

2.2.1 The Existing System............................................................................................5 

2.2.2 Future Work, The Servers .............................................................................................10 

2.3 The Map Display...........................................................................................................11 

2.3.1 The Existing System..........................................................................................11 

2.4 Future Work, The Map Display...............................................................................15 

3. UGS Integration 16

3.1 The UGS........................................................................................................................16 

3.2 The UGS Communications ...........................................................................................16 

4. Unmanned Vehicles 19

4.1 Unmanned Ground Vehicles .........................................................................................19 

4.2 Micro Air Vehicles........................................................................................................21 

4.3 Future Work ..................................................................................................................22 

Appendix: MIL-STD-2525B Symbol Classification 23

5. References 26

Acronyms 27

Distribution List 29
iv

List of Figures 

Figure 1. Simplified conceptual deployment of ARL assets in C4ISR OTM. ...............................2 

Figure 2. Agile computing middleware and cross-layer substrate..................................................5 

Figure 3. ARL server deployment and integration w CIMS and FBCB2.......................................8 

Figure 4. CIMS enhanced FBCB2 showing sensor imagery. .........................................................9 

Figure 5. CIMS enhanced FBCB2 showing text information.......................................................10 

Figure 6. Collaborative map tethering and doodling – Sketch Sharing........................................13 

Figure 7. Collaborative map tethering and doodling – File/Chat Sharing....................................14 

Figure 8. Sensor coverage and detection. .....................................................................................15 

Figure 9. UGS integration architecture.........................................................................................18 

Figure 10. ARL OCU hardware.....................................................................................................19 

Figure 11. UGV integration (communications)............................................................................20 

Figure 12. ARL UGV OCU C2 application..................................................................................21 

Figure 13. MAV integration architecture......................................................................................22 
1

1. Introduction 

Communications, Electronics, Research, Development, and Engineering Center (CERDEC’s) 

Command, Control, Communications, Computers, Intelligence, Surveillance, and 

Reconnaissance On-the-Move (C4ISR OTM) Testbed and associated experimentation began in 

2001 at the direction of Dr. A. Michael Andrews, then the Office of the Assistant Secretary of 

the Army for Acquisition, Logistics, and Technology’s Deputy Assistant Secretary for Research 

and Technology with the creation of a Special Projects Office to support the demonstration and 

evaluation of C4ISR technologies for Future Combat Systems (FCSs). The 2007 experiment 

employed over 100 different sensor, command and control, and communications systems 

augmented with a simulated Brigade-sized element (1). In this report we describe how the Army 

Research Laboratory (ARL) and CERDEC integrated unmanned ground vehicles (UGVs), a 

variety of unattended ground sensors (UGSs), and a micro air vehicles (MAVs) into the 

experiment and exercise. This report focuses on the systems, subsystems, and components 

relevant to ARL’s integration efforts. 

ARL brought several UGVs, a MAV, and both operational and experimental UGSs to the 

experiment. UGS communications was provided by an ad-hoc network of ARL-developed 

“Blue Radios”. Communications for the UGVs, operator control units (OCUs), and MAV 

ground station was provided by a mobile ad-hoc network (MANET) running on top of 802.11g. 

Communications from the UGSs and UGVs were routed to a High Mobility Multipurpose 

Wheeled Vehicle (HMMWV) serving as a communications gateway to the Soldier-Level 

Integrated Communications Environment (SLICE) Soldier Radio Waveform (SRW) radios 

providing vehicle-to-vehicle communications. Further processing and fusion of the UGS, UGV, 

and MAV data was performed on this gateway HMMWV. The results were handed off to 

CERDEC-developed software, the C4ISR Information Management Service (CIMS), which 

routed the information to other vehicles over SRW and to the network operations center/tactical 

operations center via Warfighter Information Network-Tactical (WIN-T). Ultimately the 

information was displayed using a CERDEC-enhanced version of the Force XXI Battle 

Command, Brigade-and-Below (FBCB2) mapping system. Figure 1 provides a simplified, 

conceptual view of the communications links and deployment of various assets involved in the 

integration. 
2

Figure 1. Simplified conceptual deployment of ARL assets in C4ISR OTM. 

This report is organized as follows. First we describe the ARL software infrastructure and its 

integration into the SRW network and FBCB2. Next we describe the integration of the UGSs 

and associated software. The third section describes the UGVs and their integration and 

associated software. The fourth section describes the MAV integration. Instead of identifying 

future work in a separate section, each section contains its own future work sub-section. 

2. Software Infrastructure 

2.1 The Agile Computing Middleware 

2.1.1 The Existing System 

ARL began developing middleware during the mid-1980s to mediate between applications and 

heterogeneous communication services. While Internet Protocol (IP) had been adopted and 

standardized by that time, there were (and still are) a number of devices using a variety of other 

communication protocols. Many of these protocols are standards-based, but others remain 

proprietary. ARL adopted a middleware approach to isolating and protecting applications from 

changes in the underlying communications infrastructure. This middleware provided a layer of 

abstraction which allowed the applications to communicate seamlessly and transparently across a 

variety of devices, from experimental to operational, in-house and externally developed. With 

the award of the Advanced Decision Architectures Collaborative Technology Alliance in 2001, 
3

ARL established a fruitful and ongoing collaboration with a group of researchers at the Institute 

for Human and Machine Cognition (IHMC) who shared a similar view of the benefits of 

middleware mediation. We began to explore the possibility of extending ARL’s middleware to 

provide additional capabilities not readily available from the communications infrastructure. 

These additional capabilities focused on the opportunistic discovery and exploitation of available 

resources to improve capability, performance, efficiency, fault tolerance, and survivability. 

IHMC coined the term Agile Computing Middleware (ACM) (2) to emphasize the desire to both 

quickly react to changes in the environment and exploit transient resources which may only be 

available for brief periods. ARL and IHMC have since collaborated on the further development 

of the ACM and used it in the Horizontal Fusion Quantum Leap, Command and Control of 

Robotic Entities, and C4ISR OTM experiments and exercises. Some of the ACM capabilities 

utilized in these experiments and exercises include message-based communication flows along 

the orthogonal dimensions of reliability and sequencing1, message tagging and replacement2, a 

flexible peer to peer (P2P) dissemination and organization protocol, connection monitoring, and 

service discovery permitting the dynamic registration, deregistration and migration of arbitrarily 

complex services with arbitrarily complex signatures and parameters. 

In addition, ACM, ARL, and IHMC developed a cross-layer network. The motivation behind the 

introduction of this new component arose as a result of the difficulties and vagaries encountered 

when introducing MANETs into various existing ARL systems. Generally, the introduction of 

MANETs has resulted in a rethinking of the sanctity of the OSI seven layer model3

. While 

clearly a useful architectural abstraction for designing scalable solutions via clear separation of 

concerns, the dynamic properties of MANET environments4 are causing researchers and 

developers to think about selectively exposing the layers to allow couplings to support timing 

guarantees, congestion control, quality of service (QoS) provisioning, and the like. In a wired 

environment, link bandwidth, error rates, and topology tend to be stable, allowing QoS to be 

determined upon the initial establishment of the connection with no need to modify path 

characteristics over the life of the connection. In a MANET environment, network 

characteristics can vary continuously depending on the degree of mobility of each of the 

constituent nodes. In addition to a dynamic topology, MANETs in tactical environments must 

contend with a multitude of noise sources and active interference, further increasing error rates 

 

1 Flows can be selected from one of four possible combinations: 

1) Reliable/sequenced messages are analogous to the delivery and sequencing guarantees provided by TCP. 

2) Unreliable/unsequenced messages are analogous to UDP datagrams. 

3) Reliable/unsequenced messages are provided for applications which want a delivery guarantee but don’t care what 

order they arrive at the destination. 

4) Unreliable/sequenced messages are provided for applications which don’t care that all messages are delivered but do 

care that if they arrive, they arrive in the same order they were sent (such as some of forms of streaming video). 

2 To provide for replacement of one or more messages which have been queued but not yet transmitted and which have 

become obsolete because of newer information (such as current location or state). 

3

 ISO/IEC 7498-1:1984, “Information Technology – Open Systems Interconnection – Basic Reference Model – The Basic 

Model”. 

4

 Mobility, energy concerns, spectrum/channel sharing, et al. 
4

and decreasing bandwidth. If distributed systems in a MANET have access to lower-layer 

network information, they can be made more efficient and resilient by anticipating and adapting 

to changes in the network state5. Additionally, lower MANET layers which have access to 

application-level requirements and constraints can allocate resources more optimally. The crosslayer substrate provides a common interface, allowing applications to both query and inform 

lower layers in a consistent manner regardless of the types of devices, routing, or scheduling 

protocols in use on the network. 

While applications which are individually aware of, and independently adapt to, changes in the 

network environment may result in more efficient usage of the available resources, they may also 

result in greater instability (e.g., as a result of competing requirements or greedy strategies). 

While nothing prevents applications from choosing their own adaptation strategy, group 

adaptation across an application’s collective requirements is likely to yield better results. To that 

end, we are exploring using the ACM to provide collective QoS guarantees and dynamic 

adaptation across all of the applications within a distributed system in order to better6 use the 

resources available at any given instant from a more global perspective. 

Figure 2 illustrates the components and data flows within the middleware and cross-layer 

substrate. Mockets provides connection monitoring, message tagging and replacement, and 

(un)reliable/(un)sequenced communication flows. The Group Manager provides the flexible P2P 

dissemination and organization protocol, and AgServe provides for distributed, dynamic service 

(de)registration, discovery, and migration. FlexFeed provides intelligent distribution of content 

between nodes through the use of en-route message transformation and other techniques. The 

other components illustrated were not used within C4ISR OTM. More detail may be found in (3

through 5). Note that components within the ACM are designed to work with or without the 

cross-layer substrate. Similarly, applications can communicate directly with the cross-layer 

substrate, the ACM, or even the lower-level transport layer. 

 5

 An immediate efficiency is to piggyback application data on top of any control traffic being generated by lower layers 

anyway for other purposes (e.g., the beacons and route maintenance messages associated with both proactive and reactive routing

protocols). 

6

 Decisions still have to primarily be made based solely on local decisions to minimize communications overhead introduced 

by the coordination itself. So the concept of a “globally optimal” solution is abandoned in favor of an adequate or sufficient 

assignment of resources. 
5

Figure 2. Agile computing middleware and cross-layer substrate. 

2.1.2 Future Work, The ACM 

Current efforts in this area include determining agility metrics to quantify the performance of the 

ACM, developing distributed collective coordination strategies, identifying topological and other 

communication characterizations which can support this distributed coordination, and integrating 

other communications devices within the cross-layer substrate (such as ARL’s Blue Radio.) 

2.2 The Servers 

2.2.1 The Existing System 

The current system is based around four centralized servers, each managing a different type of 

data. Producers generate data and route it to the appropriate server which then reflects the data 

to all interested consumers. The four servers are the TOS, the SOS, the Multimedia Server, and 

the Collaboration Server. This centralized approach to data storage and dissemination has 

proven to be inappropriate (if not infeasible) for a MANET environment and is used for 

historical reasons. Development of a distributed replacement for this architecture is underway. 
6

Each server in the system advertises its service type, listen endpoint,7 and protocol8 via an ARLdeveloped surrogate for the AgServe middleware component called the AgentRegistry which 

internally uses the GroupManager for distributed dissemination. Clients query the 

AgentRegistry for the location of servers providing the services they require.9 Clients initially 

connect to the server using the listen protocol specified in the server’s service advertisement. 

Clients can negotiate a protocol change if the default listen protocol is not acceptable. Direct 

communications with the servers can be transported over transmission control protocol (TCP) or 

user datagram protocol (UDP) using standard sockets, or over (un)reliable/(un)sequenced 

Mockets message flows. Indirect communications via Web Services Definition Language web 

services are also supported via the introduction of specialized gateway clients created solely for 

this purpose. 

The TOS processes MIL-STD-2525B-based extensible markup language (XML) messages. This 

server is used to disseminate position updates for every UGS, UGV, MAV, HMMWV, and other 

unit in the system. It is also used to disseminate operational and tactical graphics, enemy 

positions and activities, and any other information within the scope of MIL-STD-2525B. This 

information is ultimately visualized for the end user as symbols displayed on a mapping system. 

The SOS collects and disseminates UGS detections and sensings. The server supports reporting 

of lines of bearing, proximal activity, electronic signatures and target locations. Messages to and 

from this server are formatted as XML conforming to an ARL-developed schema. This server’s 

primary purpose is to provide a single collection point for data fusion applications. It is also 

used to support visualization of all sensor activity and state as an engineering or diagnostic aid. 

The Multimedia Server stores and disseminates images, movies, audio reports, and other large 

binary objects. When multimedia data is collected by an UGS, an operator, or other process, the 

data and its associated metadata are pushed to the server which stores the data locally and 

reflects the metadata to notify other consumers of the existence of the new collect. 

The Collaboration Server supports the tethering of map displays across users, the dissemination 

of attentional sketches and other graphical annotations, text chat, and file transfer. Users may 

collaborate using either a free-form or moderated protocol. In free-form groups users may join, 

leave, or create any session at any time; they may tether to/untether from, share sketches, send 

files, and chat with any other user in the session at any time. In a moderated session all of these 

activities must be approved (at least initially) by the moderator. By default, the moderator is the 

user who created the session, but any user who later joins can become the moderator with the 

 7 IP address and port number. 

8 TCP, UDP, or Mockets. 

9 This query is typically persistent allowing clients to request a server which is not yet available, continue to do 

other processing, and then connect to the server asynchronously later when its existence is pushed to them. Via the 

connection monitoring capabilities of the middleware, it also allows for servers to disappear and reappear (for 

whatever reasons) with minimal impact on the clients.
7

current moderator’s approval. Moderators can also force other users to tether their map to 

another user (or nobody), and to share their sketches or not. 

None of these servers have inherent support for persistence. Persistence is provided via special 

consumers which attach to the servers and store the reflected reports in a database or other file. 

Figure 3 shows the deployment of these servers and supporting software within the C4ISR OTM 

experiment. The servers were intentionally deployed on a vehicle other than the UGSUGV/SRW Gateway HMMWV to demonstrate that the ACM, cross-layer, and distributed 

discovery components would interoperate seamlessly across different networks. 
8

Figure 3. ARL server deployment and integration w CIMS and FBCB2. 

In addition to the ARL servers and archiving clients described above, a set of fusion process 

collectively known as Sensed Object Server (SOS)-to-Tactical Object Server (TOS) receives raw 

detections from the SOS and sends MIL-STD 2525B unidentified, unaffiliated ground track 

symbols to the TOS for dissemination. Unknown ground track symbols are created where 

acoustic bearings within a temporal window intersect and at the location of a tripwire or 
9

proximity sensor detecting activity. Since there was no facility within FBCB2 for displaying raw 

sensor activity, these unidentified moving object symbols cued the FBCB2 operators where 

activity was occurring and which camera captures should be examined. To minimize the amount 

of clutter on ARL’s map display, SOS-to-TOS deletes the detection symbols from the TOS after 

10 seconds. FBCB2 has its own decay mechanism that ages symbols based on time of last 

report. SOS-to-TOS also sends sensor status reports to TOS every 5 minutes to inform the 

operators of UGS state and to prevent FBCB2 from aging the UGS symbols away. 

TOS-to-CIMS and MM-to-CIMS attach, respectively, to the TOS and Multimedia Server as 

clients. They expose a listen socket on a predefined port that the CIMS conduit attaches to. 

Received data is passed to the CIMS conduit via the socket. For tactical symbols, this 

communication is bidirectional. The CIMS Conduit uses the CIMS Gateway to provide reliable 

communications over the SRW SLICE network and wraps additional user interface (UI) 

elements around FBCB2 to provide network status, chat, and imagery capabilities via the CIMS 

Information Server. Figures 4 and 5 show examples of the CIMS-enhanced FBCB2 display that 

was presented to the operators. 

Figure 4. CIMS enhanced FBCB2 showing sensor imagery. 
10

Figure 5. CIMS enhanced FBCB2 showing text information. 

2.2.2 Future Work, The Servers 

The major problem with the current architecture is the reliance on communication with a 

centralized server. Such communication cannot be guaranteed in the highly mobile, 

intermittently connected network environment typical of MANETs. However, there are 

advantages to this centralized approach in more robust environments like those provided by 

WIN-T and the global information grid. Our current development efforts focus on removing the 

dependencies on these servers by relocating them from the core to the periphery of the system, 

where they will continue to serve as gateways to other systems. To accomplish this, we plan to 

create specialized P2P groups using the Group Manager component in the ACM. The data 

reflection function currently performed by the servers will be replaced by dissemination through 

these P2P groups. External systems can continue to interface with the ARL system by sending 

and receiving information using the current server interfaces, but the gateway servers will simply 

function as peers within the P2P group and will no longer maintain the single, authoritative data 

repository. 

A more subtle problem with the current architecture is that the servers typically maintain a thread 

for each connected consumer and unicast all reflected data to them. This is clearly inefficient 

when most or all of the clients have the same data requirements. Moving to the distributed P2P 
11

approach will allow us to gain some efficiencies from the multicast strategy used by the Group 

Manager. In situations where clients have differing data requirements, an intelligent approach 

like that provided by FlexFeed within the ACM is more appropriate. 

Different types of servers will warrant different P2P strategies and structures. For supporting 

and maintaining situational awareness by periodically distributing position data to all nodes as 

efficiently as possible, simple epidemic and broadcast protocols may suffice. For sensor and 

data fusion, the data may be useless if it isn’t delivered to fusion centers quickly and efficiently. 

In this case, the fusion centers (and the communication routes to them) become differentiated 

from their peers by virtue of their importance. For human collaboration, the peers and groups 

emerge dynamically as a result of user-to-user interactions10 and may bear little resemblance to 

the underlying network topology. In these situations it is advantageous to dynamically adapt the 

dissemination protocol and associated distributed data structures to better match the higher level 

network environment. 

2.3 The Map Display 

2.3.1 The Existing System 

The mapping system ARL used for this effort was developed beginning in 2002 as a project for 

the Intelligence and Security Command (INSCOM). The fundamental ideas were that 1) map 

displays can be tethered to ensure that collaborators are “on the same page”, 2) sketches and 

other annotations drawn on the map can be shared to enhance collaboration, and 3) laydown of 

control measures and other tactical graphics specified in MIL-STD-2525B can be facilitated by 

allowing users to draw them free-hand with a touch screen, stylus, or mouse. Because of its 

focus on the use of free-hand drawings to support collaboration and intelligence preparation of 

the battlefield, this application, coupled with the Collaboration Server and supporting 

infrastructure, became known as Digital Ink. 

Digital Ink is implemented as an extension into ESRI’s ArcMap application. It consists of 3 

main components: symbology, collaboration, and sensor coverage display. The symbology 

component supports the free-hand lay-down and real-time display of MIL-STD-2525B 

symbology. MIL-STD-2525B specifies graphical templates for each of the symbols. The 

standard provides a different template for each symbol. We classify each template into one of 

ten categories (detailed in the appendix.) 

While many systems use the individual symbol templates explicitly for both symbol creation and 

manipulation, there may be efficiency gains if these template categories are superimposed on 

appropriately attributed11 free-hand drawings and the defining points are extracted 

algorithmically. In this system, users select the type of symbol they want to create from a 

 10 Who wants to (or should) tether to whom, who wants to (or should) share sketches or other attentional ink or graphical 

annotation with whom. 

11 Namely with the MIL-STD-2525B symbol identification code. 
12

graphical palette of recently or frequently used symbols.12 They are then prompted to draw the 

appropriate category (draw a U for a U-shaped template category, draw a J for a J-shaped 

category, etc.). Once this has been done, they draw the location and basic shape for the category. 

The defining points for the template category are then extracted, and a new symbol is added to 

the user’s map and sent to the TOS for dissemination to others. The real-time rendering of 

symbology is implemented by double-buffering the map display generated by ArcMap and 

sending the bitmap and associated geographic coordinates to TRW’s Graphical Symbology 

Display library to render the symbols. 

The collaboration component supports user-to-user collaboration through the Collaboration 

Server. Users can share sketches and other graphical annotations, tether map displays, chat and 

send files via this interface. When sharing sketches, the client-side application renders each line 

segment as it is received instead of waiting until the entire sketch has arrived. This effectively 

captures the temporal aspect associated with the creation of the sketch allowing users to convey a 

sense of urgency to their annotations. Figure 6 shows an example of the tethering and sketch 

sharing UI with some explanatory notations. Figure 7 shows an example of the chat and file 

sharing UI. 

 12 Or using a dictionary indexed along a variety of dimensions including lexically and hierarchically. 
13

Figure 6. Collaborative map tethering and doodling – Sketch Sharing. 
14

Figure 7. Collaborative map tethering and doodling – File/Chat Sharing. 

The sensor coverage component is used to display range fans, lines of bearing, directional 

arrows, and other detection indicators to illustrate sensor coverage and activity. Examples of 

these capabilities are shown in figure 8. 

In the upper center portion of this the range fans of two cameras mounted on a building roof are 

displayed. The coverage than can be achieved by these cameras is reported by the camera rather 

than being “made up” by the display program. As a consequence, the map display has the ability 

to display “true” information which may be used by the operator for planning purposes. Note 

from the figure that the upper two cameras (looking Northward) have overlapping fields of view. 

In situations such as this, it is possible to transfer use of one camera to another as an object of 

interest moves from the view of one camera to the view of both cameras to the view of the other 

camera. 

Also shown in figure 8 is an infrared tripwire sensor. This sensor is the yellow symbol just to the 

right and below the center of the figure. The field of view of this sensor is shown in a manner 

that is identical to the field of view display for the camera. That is, the field of view is reported 

by the sensor it self. This particular tripwire sensor also reports the line of bearing of objects that 

cause it to trip. The red line that runs up center of the field of view of the tripwire sensor is such 

a report. 
15

Figure 8. Sensor coverage and detection. 

As the sensors themselves are actually reporting their characteristics, the map display can be a 

very useful tool in planning the location of sensors and a very useful tool for analyzing targets as 

they move through fields of sensors. It is also true that since the sensors report their own 

characteristics, there is a potential to automate much of the processing that might be done by a 

human using the map display as an analysis tool. 

2.4 Future Work, The Map Display 

Digital Ink is currently integrated with ESRI’s ArcMap application as an ArcMap extension. We 

decided to plug into ArcMap instead of using ESRI’s ArcEngine as a library underneath an ARL 

application because INSCOM Intelligence Analysts were already familiar and comfortable with 

ArcMap. With the award of the Commercial Joint Mapping Toolkit (C/JMTK) contract, a DoDwide license has been created for the development of C2 systems. The ArcEngine and associated 

developer kit are included in the license agreement, but the ArcMap Desktop application is not. 

Our current efforts include re-implementing Digital Ink as a standalone application using 

ArcEngine. Additionally, TRW’s Graphical Symbology Display is no longer supported, so we 
16

are replacing the rendering of symbology with ESRI’s Military Overlay Editor, which is part of 

the C/JMTK. 

3. UGS Integration 

3.1 The UGS 

ARL integrated four operational and two experimental UGS systems into the C4ISR OTM 

experiment. Three of the operational systems were developed for the Army and one was 

developed for the United States Marine Corps (USMC). The Army UGS included one 

OmniSense system provided by McQ Inc., one Scorpion system provided by Northrop 

Grumman, and one Silent Watch system provided by Harris. The USMC UGS consisted of one 

Tactical Remote Sensor System (TRSS). All four sensor systems contained at least one imager. 

To minimize power consumption, the imagers and associated processors typically remain in a 

low power state until cued by activity sensors. The activity sensors on all four operational 

systems are capable of detecting both vehicles and personnel in the vicinity. The OmniSense 

system employed in the experiment consisted of visible and thermal imagers cued by seismic, 

acoustic, and passive infrared (PIR) activity sensors. The Scorpion system contained both 

visible and thermal imagers cued by magnetic and seismic activity sensors. The Silent Watch 

system contained a low light visible imager and an thermal imager cued by seismic and PIR 

activity sensors. The TRSS contained visible and thermal imagers cued by activity sensors 

which can be configured to use acoustic, seismic, or PIR transducers. 

ARL also integrated two internally developed experimental sensor systems: a MMS system and a 

Tripwire Camera (TWC). The MMS is a very low-cost non-imaging system consisting of a 

number of single-package seismic, acoustic, and PIR transducers. Depending on the desired or 

observed specificity and sensitivity during operations, the MMS can be configured to generate 

activity reports only when certain combinations of the three sensors are activated. The MMS 

does not provide localization and only reports that activity is occurring in its proximity. One 

MMS sensor suite, consisting of six sensors and a gateway node, was employed during the 

experiment. The TWC consists of an off-the-shelf low-cost daytime color imager commonly 

used in cell phones cued by a PIR motion detector. The camera remains idle until the PIR 

detector activates it in response to motion in its field of view. After image capture, the image 

and direction of motion are packaged into a sensor report for delivery back to the UGS/UGVSRW gateway HMMWV. Two TWCs were employed during the experiment. 

3.2 The UGS Communications 

While each UGS comes with its own communications system, ARL is promoting the idea of 

common communications protocols and devices as part of its Family of UGS concept. As ARL 

has not yet identified a suitable standard protocol and the developers of three of the four 
17

operational systems already had some experience with McQ Inc.’s Common Data Interchange 

Format (CDIF), for the sake of expedience CDIF was chosen as the common communications 

protocol for this experiment. ARL’s Blue Radio was used as the common communications 

device. The Blue Radio provides secure long range data communications in the tactical ultra 

high frequency (UHF) frequency band. Battery life is maximized by intelligently managing the 

transmitter and receiver power of the radio. Multiple radios will discover each other and form an 

ad hoc network amongst themselves. Although direct communications between any two radios 

is possible, in practice one or more radios is configured to be a gateway or sink which every 

other radio will establish a route to. 

For C4ISR OTM, a Blue Radio was mounted in the UGS/UGV-SRW gateway HMMWV and 

configured as the only gateway in the Blue Radio network. Since OmniSense already used the 

CDIF protocol, the only change required to integrate it into the experiment was to replace its 

communications device with the Blue Radio. For the Scorpion and Silent Watch sensors, a 

separate laptop computer was used to bridge between them and the Blue Radio network. Since 

these systems already used serial radios for their native communications, the original radio was 

simply removed and replaced by the laptop/Blue Radio equipment. The radio plugged into a 

second serial port on the laptop. Additionally, Scorpion and Silent Watch used the laptop to 

translate from their native protocol into CDIF just prior to transmission over the Blue Radio. 

There was insufficient time to translate the TRSS native protocol into CDIF; the Blue Radio was 

already integrated with its imager’s processor. As a result, no laptop was necessary, but special 

TRSS message handlers had to be installed on the UGS/UGV-SRW gateway HMMWV. The 

TWC and MMS were designed to use the Blue Radio natively so no laptop or other 

communications bridge was necessary. However, there was insufficient time to develop the 

software to translate their native protocols into CDIF so special handlers were installed on the 

gateway similar to the TRSS. Figure 9 shows the deployment of relevant components used 

during the experiment from the perspective of the UGS. 
18

Figure 9. UGS integration architecture. 
19

4. Unmanned Vehicles 

4.1 Unmanned Ground Vehicles 

ARL integrated three iRobot PackBot Explorers into the experiment. The PackBots were 

equipped with a communications payload developed by ARL and IHMC. This payload consisted 

of a Linksys 802.11g wireless router running OpenWRT Whiterussian custom firmware and an 

open source Optimized Link State Routing (OLSR) routing daemon. In addition to the custom 

payloads, ARL developed its own OCU software. This software was installed on ruggedized 

Itronix Duo-Touch Windows XP Tablet PCs that had been modified to use Army standard BB2590 compatible batteries. Communications were provided by the same type of Linksys router 

used on the PackBot communications payload. The OCU was equipped with dual CH Products 

industrial joysticks mounted on a frame bolted to the tablet PC. Three OCUs were used during 

the experiment. Figure 10 shows the OCU hardware. The Linksys router is mounted underneath 

the tablet. 

Figure 10. ARL OCU hardware. 

A communications payload similar to that on the PackBot was mounted on the UGS/UGV-SRW 

gateway HMMWV. UGV and OCU data were routed to the TOS for dissemination to other 

OCUs (for SA), to higher echelons via WIN-T, and to other local HMMWVs via SRW. The 
20

software components and data flow for these activities is described in more detail in a later 

section. Figure 11 shows the asset deployment and communications links from the UGV 

perspective. 

Figure 11. UGV integration (communications). 

In addition to the new payload, ARL installed video, control, telemetry, and middleware 

software on the main PackBot processor. ARL’s control and telemetry software uses the iRobot 

Aware 1.2 Robot Intelligence Software to control the PackBot and acquire positional and other 

telemetry data. The video software replaces the iRobot video server and supports sending either 

MPEG-4 or Motion JPEG video streams to an arbitrary number of clients at user-selectable 

frame rates, resolutions, and compression levels. The control software supports both low-level 

(e.g., move forward at 1 m/s) and mission-level (e.g., navigate to these waypoints) commands. 

Both the video and control software advertise their services through the distributed discovery 

mechanisms provided by the ACM. 

The OCU software consisted of the Digital Ink map display described earlier which provided SA 

for the PackBots’ positions and all other global positioning system (GPS)-equipped assets in the 

experiment combined with a C2 application which allowed the operators to control and monitor 

any of the robotic assets. Operators have the ability to capture and annotate individual images 

from any of the video feeds and submit them to higher echelons. Any OCU can be used to 

control any robotic asset. Operator contention is handled by locking out other operators once an 

OCU has control. The current availability status of the robot is indicated on the display. A 

commandeer capability exists allowing an operator to override this lockout in an emergency or 
21

exceptional situation. The OCU software uses the distributed discovery services provided by the 

ACM to discover the available robotic assets. Figure 12 shows an image of the OCU control 

software. 

Figure 12. ARL UGV OCU C2 application. 

4.2 Micro Air Vehicles 

ARL partially integrated the Nighthawk MAV developed by Applied Research Associates into 

the C4ISR OTM experiment. The Nighthawk is a man-portable, hand-launched unmanned air 

vehicle capable of autonomous flight using an integrated GPS and autopilot. The vehicle is 

equipped with multiple video cameras. The Nighthawk system is comprised of the MAV itself, a 

laptop-based control station, and a remote video receiver. The control station uses the 

FalconView mapping system for MAV tasking and SA. 
22

ARL injected the MAV telemetry data into C4ISR OTM by connecting a gateway laptop to a 

serial port on the control station laptop that was configured to stream NMEA 0183-like telemetry 

data. This data was sent to the TOS for further dissemination. The remote video terminal 

received wide-band NTSC analog video over a 2.4GHz link. The NTSC-Out port of the remote 

video receiver was connected to a USB frame grabber on the gateway laptop and exposed the 

video feed to remote systems in the same manner as that described for the UGVs. Figure 13 

shows the deployment of relevant components used during the experiment from the perspective 

of the MAV integration. 

MAV

CONTROL STATION

MAV

AIRCRAFT

VIDEO RECEIVER

FRAME GRABBER

ARL OCU

802.11G

MANET ROUTER

CONTROL, GPS, 

VIDEO VIDEO

VIDEO

USB VIDEO

GPS

SERIAL DATA

ETHERNET

ORIGINAL MAV SYSTEM ARL ADDITIONS

Figure 13. MAV integration architecture.

4.3 Future Work 

As part of the Family of UGS concept, ARL is investigating the use of cross-asset tipping and 

cueing between UGS, UGVs, and MAVs. For example, an UGS field may exhibit enough 

interesting activity to warrant further investigation. This further investigation could be carried 

out autonomously by UGVs or MAVs if the assets could be automatically tasked. Initially, we 

plan to generate waypoints and missions based on UGS and UGV reports and task the 

Nighthawk MAV using STANAG 4586 messages sent to a socket-based server running on the 

Nighthawk control station. 
23

Appendix: MIL-STD-2525B Symbol Classification 

1) Point templates have a single anchor point, 

2) Area templates use all of the input points, 

3) Line templates 

a. Unsampled line templates use all of the input points with the start and end points 

designated as anchor points, 

b. 2-point line templates use only the start and end points, 

4) Arrow templates use the start point, the tip of the arrow head, and the location of one of the 

arrow head end points as anchor points, 

5) Circle templates use the start point and the center point as anchor points, 
24

6) V-shaped templates use the base point of the V and the 2 top end points as anchor points, 

7) L-shaped templates use the start point, bend point, and end point as anchor points, 

8) J-shaped templates use the start point, bend start point, and end point as anchor points, 

9) T-shaped templates use the two top end points and base point as anchor points, 

10) U-shaped templates 

a. 3-point U-shaped templates use the two top end points and the mid-point of the base as 

anchor points, 
25

b. 4-point U-shaped templates use the two top end points and two base points as anchor 

points, 
26

5. References 

1. Press Release, CERDEC, PM C4ISR OTM Office, 20 June 2007 

2. Suri, Niranjan; Bradshaw, Jeffrey M.; Carvalho, Marco M.; Cowin, Thomas B.; Breedy, 

Maggie R.; Groth, Paul T.; Saavedra, Raul. Agile Computing: Bridging the Gap between 

Grid Computing and Ad-hoc Peer-to-Peer Resource Sharing. Proceedings of the 3rd

IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2003), 

(May 2003), pp. 618–625. 

3. Suri, N.; Rebeschini, M.; Arguedas, M.; Carvalho, M.; Stabellini, S.; Breedy, M. Towards 

an Agile Computing Approach to Dynamic and Adaptive Service-Oriented Architectures. In 

Proceedings of the First IEEE Workshop on Autonomic Communication and Network 

Management (ACNM'07). 

4. Suri, N.; Rebeschini, M.; Breedy, M.; Carvalho, M.; Arguedas, M. Resource and Service 

Discovery in Wireless Ad-Hoc Networks with Agile Computing. In Proceedings of the 2006 

IEEE Military Communications Conference (MILCOM 2006), Washington, D.C., October 

2006. 

5. Carvalho, M.; Suri, N.; Arguedas, M. Mobile Agent-based Communications Middleware for 

Data Streaming in the Battlefield. In Proceedings of the 2005 IEEE Military 

Communications Conference (MILCOM 2005), Atlantic City, New Jersey, October 2005. 
27

Acronyms 

ACM Agile Computing Middleware 

ARL Army Research Laboratory 

C/JMTK Commercial Joint Mapping Toolkit 

C2 Command and Control 

C4ISR OTM Command, Control, Computers, Communications, Intelligence, 

Surveillance, and Reconnaissance On-the-Move 

CDIF Common Data Interchange Format 

CERDEC Army Communications, Electronics Research, Development, and 

Engineering Center 

CIMS C4ISR Information Management Service 

DoD Department of Defense 

FBCB2 Force XXI Battle Command, Brigade-and-Below 

FCS Army Future Combat Systems 

GPS Global Positioning System 

HMMWV High Mobility Multipurpose Wheeled Vehicle 

IHMC Institute for Human and Machine Cognition 

INSCOM Army Intelligence and Security Command 

IP Internet Protocol 

MANET Mobile Ad-Hoc Network 

MAV Micro Air Vehicle 

MIL-STD-2525B Department of Defense Common Warfighting Symbology Standard 

MMS Multi Modal Sensor 

OCU Operator Control Unit 

OLSR Optimized Link State Routing 

OSI Open Systems Interconnection 
28

P2P Peer to Peer 

PIR Passive Infrared

QoS Quality of Service 

SA Situational Awareness 

SLICE Soldier-Level Integrated Communications Environment 

SOS Sensed Object Server 

SRW Soldier Radio Waveform 

TCP Transmission Control Protocol 

TOS Tactical Object Server

TRSS Tactical Remote Sensor System 

TWC Tripwire Camera 

UDP User Datagram Protocol 

UGS Unattended Ground Sensor 

UGV Unmanned Ground Vehicle 

UHF Ultra High Frequency 

UI User Interface 

USMC United States Marine Corps 

WIN-T Warfighter Information Network-Tactical 

XML Extensible Markup Language 
29

Distribution List

NO.

COPIES ORGANIZATION

1 ADMNSTR 

(ELECT DEFNS TECHL INFO CTR 

COPY) ATTN DTIC OCP 

 8725 JOHN J KINGMAN RD 

 STE 0944 

 FT BELVOIR VA 22060-6218 

1 DARPA 

 ATTN IXO S WELBY 

 3701 N FAIRFAX DR 

 ARLINGTON VA 22203-1714 

1 OFC OF THE SECY OF DEFNS 

 ATTN ODDRE (R&AT) 

 THE PENTAGON 

 WASHINGTON DC 20301-3080 

1 US ARMY RSRCH DEV AND 

 ENGRG CMND 

 ARMAMENT RSRCH DEV AND 

 ENGRG CTR 

 ARMAMENT ENGRG AND 

 TECHNLGY CTR 

 ATTN AMSRD AAR AEF T 

 J MATTS 

 BLDG 305 

 ABERDEEN PROVING 

 GROUND MD 21005-5001 

1 US ARMY TRADOC 

 BATTLE LAB INTEGRATION & 

 TECHL DIRCTRT 

 ATTN ATCD B 

 10 WHISTLER LANE 

 FT MONROE VA 236515850 

2 JTRS NED 

 ATTN LTC K EVENSEN 

 1777 N KENT STREET 

 ARLINGTON VA 22209 

4 U.S. ARMY RSRCH LAB 

 ATTN AMSRD CER OTM 

 C HOLGUIN 

 BLDG 2700 RM 4D201 

 FT MONMOUTH NJ 07703 

NO.

COPIES ORGANIZATION

1 US ARMY CERDEC S&TCD 

 ATTN AMSRD CER ST WL SF 

 MAJ ROJAS 

 BLDG 2700 CORREGIDOR AVE 

 FT MONMOUTH NJ 07703 

1 US ARMY INFO SYS ENGRG 

 CMND 

 ATTN AMSEL IE TD F JENIA 

 FT HUACHUCA AZ 85613-5300 

1 COMMANDER 

 US ARMY RDECOM 

 ATTN AMSRD AMR 

 W C MCCORKLE 

 5400 FOWLER RD 

 REDSTONE ARSENAL AL 

 35898-5000 

3 US ARMY RSRCH LAB 

 ATTN AMSRD CER OTM 

 LTCOL W T UTROSKA 

 (2 COPIES) 

 ATTN AMSRD CER OTM 

 M AMABILE 

 BLDG 2700 RM 4D201 

 FT MONMOUTH NJ 07703 

1 US ARMY RSRCH LAB 

 ATTN AMSRD ARL CI OK TP 

 TECHL LIB T LANDFRIED 

 BLDG 4600 

 ABERDEEN PROVING 

 GROUND MD 21005-5066 

1 US GOVERNMENT PRINT OFF 

 DEPOSITORY RECEIVING SECTION 

 ATTN MAIL STOP IDAD J TATE 

 732 NORTH CAPITOL ST NW 

 WASHINGTON DC 20402 

2 FLORIDA INSTIT FOR HUMAN & 

 MACHINE COGNITION 

 ATTN N SURI 

 40 S ALCANIZ STREET 

 PENSACOLA FL 32502 
30

NO.

COPIES ORGANIZATION

2 U.S. ARMY RSRCH LAB 

 MANPRINT RSRCH & ANALYSIS BR 

 ATTN AMSRD ARL HR MX 

 E K BOWMAN 

 ABERDEEN PROVING GROUND MD 

 21005 

1 DIRECTOR 

 US ARMY RSRCH LAB 

 ATTN AMSRD ARL RO EV 

 W D BACH 

 PO BOX 12211 

 RESEARCH TRIANGLE PARK NC 

 27709 

33 US ARMY RSRCH LAB 

 ATTN AMSRD ARL CI OK T 

 TECHL PUB 

 ATTN AMSRD ARL CI OK TL 

 TECHL LIB 

 ATTN AMSRD ARL CI C B BROOME 

 ATTN AMSRD ARL CI CB 

 B O'BRIEN (2 COPIES) 

 ATTN AMSRD ARL CI CB 

 C WINSLOW (5 COPIES) 

 ATTN AMSRD ARL CI CB D BARAN 

 ATTN AMSRD ARL CI CB 

 J KOVACH (5 COPIES) 

 ATTN AMSRD ARL CI CB 

 L TOKARCIK (5 COPIES) 

 ATTN AMSRD ARL CI CB 

 R WINKLER (5 COPIES) 

 ATTN AMSRD ARL CI CB S CHOY 

 ATTN AMSRD ARL CI CB 

 S H YOUNG 

 ATTN AMSRD ARL CI CB 

 T GREGORY (5 COPIES) 

 ATTN MAIL AND RECORDS 

 MANAGE MENT 

 ADELPHI MD 20783-1197 

Total 58 (57 hard copies, 1 electronic copy)