A Communication Protocol for Unmanned Ground

Vehicles
Bani Hazra

Alok Mukherjee

Vishal Veer Singh

R&DE(E), DRDO, Pune

Maharastra,
India

R&DE(E), DRDO, Pune

Maharastra,
India

R&DE(E), DRDO, Pune

Maharastra
India

hbani@rde.drdo.in

aamukherjee@rde.drdo.in

vishal@rde.drdo.in

ABSTRACT
The recent impetus in the area of development of Unmanned
Ground Vehicles (UGV) for various civilian and military
applications necessitates a robust and standard communication
protocol for remote operations over wireless and other media. The
Unmanned Ground Vehicle (UGV) may be of varied size, weight
and shape intended for different roles or end use and applications.
A generalized communication software protocol for UGVs has
been proposed through this work. Entire messaging vocabulary for
basic command and control of UGVs has been derived. The logical
hierarchy of different UGVs has been taken into design
consideration facilitating future collaborative nature of
deployment. This Communication Protocol implementation is
divided into two segments Master Control Station (MCS)
segment and Unmanned Ground Vehicle segment. A pair of
Communication Controllers has been realized for deployment at
both the segments for message formation and management.
Communication Controller performs the job of message
management through several queues and communicates with the
different on-board modules of the unmanned platform. A Software
simulator has been designed and implemented for validation of the
Communication Protocol in SIL (Software-In- Loop) test mode.
The system has also been validated with HIL (Hardware-In-Loop)
testing.

Keywords
Unmanned Ground Vehicle, Localization, Obstacle Detection,
Collision Avoidance, Path Recognition, Perception, Scheduler,
Queue Handler, Latency, Throughput.

1.

INTRODUCTION

The recent impetus in the area of development of Unmanned

Ground Vehicles for various civilian and military applications
necessitates a robust and standard communication protocol for
remote operations over wireless and other media. The UGV may
be of varied size, weight and shape intended for different roles or
end use and applications. Another governing factor with the
physical size and shape of the UGV is the area of application or
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. Copyrights for
components of this work owned by others than ACM must be honoured.
Abstracting with credit is permitted. To copy otherwise, or republish, to
post on servers or to redistribute to lists, requires prior specific permission
and/or a fee.
Request permissions from Permissions@acm.org.
AIR '13, July 04 - 06 2013, Pune, India Copyright 2013 ACM 978-1-45032347-5/13/07$15.00.
http://dx.doi.org/10.1145/2506095.2506143

environment of deployment. In actual terms these factors translate

to specifics such as the range of operations, terrain classification,
speed of deployment, payload capacity etc. In effect this would
mean that depending on the role or application the UGV would be
designed to carry out the intended mission.
Although the type and class of the UGV may be different, the basis
of control or communication with the vehicle shall be similar. The
type of commands that need to be sent to the UGVs shall be
identical irrespective of the platform. The only variability would be
in the type and volume of the data interchange with the role based
payloads. As it is evident, the different platforms would use
different hardware as their controller as well as for
communications. The UGVs would be provisioned with
communication hardware depending on their application or
payloads and their theatre of operations. At the physical layer, the
designer would be selecting the hardware defining its frequency of
operation, mode (analog or digital), RF power, networking
capability etc. Notwithstanding the above, it is pertinent to note
that the language of communication or messaging protocol needs
to be standardized to ensure interoperability[1]. This would enable
compatibility between operator and UGV of different types,
between UGVs in a collaborative environment [2] and also should
seamlessly integrate with future manned-unmanned network
centric systems[3].
The evolution of the UGVs would encompass different modes of
operations which could be classified as the Family to which it
belongs. The first family of UGVs would be Remotely Operated
Platforms which would be unmanned and controlled over an
intended geographical area which would be called its Range.
These platforms would operate in master slave configuration
wherein the Master Control Station would be always in contact
and control of the slave platform. These platforms would be
enhanced with sensors to enable them to accurately calculate their
own position. This process of localization of the platform with
respect to global coordinates (latitude-longitude-altitude) or with
local coordinates within a pre-mapped or known area would enable
them to be loaded with intelligence to thereafter decide on the path
to be taken. The platforms would then evolve into a class of
Automated Ground Vehicles wherein they could be programmed
to traverse unaided between waypoints over a route. The
intelligence on these platforms would thereafter be enhanced
further to enable them to carry out path planning and find alternate
routes to any destination point. The platforms would have to be
equipped with advance sensors for perception wherein obstacle
detection, collision avoidance as well as path recognition within an
area of operation would ultimately lead to a family of Autonomous
Ground Vehicles.

Although the UGVs will evolve and transform from tele-operated

vehicles to intelligent platforms, it is pertinent to note that human
control shall always be ensured such that the system can be taken
over or destroyed at any time in case of any eventuality. The
degree of human control shall keep decreasing as the platforms
gain in intelligence, however, at any point of time the operators
overall control shall be mandatory. The UGVs shall also be tasked
to work collaboratively to achieve an intended goal [4]. This would
necessitate communication within group as well as between
groups. Hence it is imperative that a language or Communication
Software Protocol (CSP) be established to enable messaging is
such scenario. This paper elucidates the design aspects of the CSP
that has been conceived and realized and discusses the test results
of its evaluation in terms of efficiency, latency and throughput.

Every class of UGV is associated with a certain rank, which

indicates the hierarchical status of the UGV within the formation.

2. DESIGN OF COMMUNICATION
SOFTWARE PROTOCOL
Figure 1. The Model Hierarchical Structure
The Communication Software Protocol (CSP) is designed
specifically for UGV control and the control of allied equipment
and systems which would normally reside on it. The CSP has been
designed with the following features:

The protocol should be Platform or Vehicle Independent [1]

The protocol implementation should be Hardware Independent
Technology Upgrades or changes should not hamper the
application of the protocol[2]
The protocol should be Mission Independent irrespective of the
area of application.

Next, every UGV shall bear a unique individual id, which shall
facilitate the addressing of UGV or MCS as a unit. Last, every
UGV or MCS shall comprise of different entities. These entities
are the actual physical units which will perform the intended task
and are categorized depending upon their logical functionalities. A
UGV or MCS may hence comprise of several entities working
within themselves. This forms the logical hierarchy of different
UGVs and entities working within them.

2.2 Design of Messaging Structure

Although there exists two standards globally for command and
control of Unmanned Platforms viz. JAUS[5] and STANAG
4586[6], these were evolved for UGVs and UAVs respectively[2].
While JAUS primarily focuses on command and control,
STANAG 4586 concentrates on data from payloads. The protocol
proposed hereunder takes into account both these aspects in its
design along with collaborative deployment.

2.1 Proposed Hierarchical Model

The applicability of the protocol in various environment including
both hardware and software, calls for conceptualizing a strong yet
flexible model which shall facilitate easy implementation and wide
acceptance as a standard. The model should encompass or include
all aspects which are associated with control of a UGV. The logical
hierarchy of different UGVs has been taken into design
consideration facilitating future collaborative nature of operation.
Primarily, the model described hereunder consists of different
groups of UGVs[1] and MCS working in collaboration. It is
assumed that groups of UGVs shall work in collaboration so as to
complete different tasks assigned to them. The basic
communication elements are demonstrated in the following figure
and are explained in the following section.
A formation is identified as a group of UGVs or MCS intended to
complete a specific mission. A group may hence consist of several
types of UGVs or MCS but all intended to complete a specific
mission. A whole mission may comprise of certain tasks, thus a
type of UGV defines a set of UGVs within a group, which are
capable of performing a specific task, e.g. a group may consists of
several types of UGVs like surveyors, communicators, suppliers,
fighters, etc. Every type is further divided into classes depending
upon the capabilities, functionalities, or version of the UGV
belonging to that specific type e.g. wheeled, tracked, biped, etc.

The messaging structure has been devised to support the above

mentioned hierarchical model while communicating between a
group of UGVs or MCS. Any information intended to be
exchanged between UGVs or MCS, may be of variable length
which needs to be communicated using a variable length packet
based service. Any information beyond the maximum allowable
size of a packet shall be broken down into pieces and shall be
communicated via multiple packets. Each packet of information
shall consist of a message header, associated data and error-check
information. A brief discussion on these units is presented
hereunder.

Figure 2. The Message Structure

The message header will comprise of several identifier fields like
start of packet identifier, address information, information priority,
the absolute message intended to be communicated etc. The field
SOP is start of packet identifier field. Then follows the address
information about the originator (source- SRC) and the receiver
(destination - DST) of the packet, which includes group id, type id,
class id, rank, individual id and entity id. The transaction id (TR
ID) shows the current transaction number for the particular
message. The message attribute field shall depict whether the
information is a single-packet or multi-packet. Also this field
informs about the message class and priority. The field packet
number indicates the packet number in a multi-packet scenario.

The field variable data size indicates the number of actual data
bytes that follow the header. And the field absolute message
informs the entity about the specific task which is intended to be
completed by that entity. The actual data follows after message
header. This data may be of variable size and its size is indicated in
the variable data size field in the message header. As stated earlier
that the maximum length of the information packet is fixed, hence
if the data size exceeds the limits of a single packet, then it has to
be broken down into smaller pieces and these packets shall be
transmitted individually with a proper identifier in the field packet
number. Error Check is the last field of message. The error check
ensures efficient and error-free transmission of information, and
facilitates retransmission of information in case of an error in
reception.

2.3 Message Management

The protocol suggested here deals with communication between
two or more individuals with the help of generating and passing
messages among themselves. Hence each individual unit shall
comprise of a Communication Controller that shall either generate
messages as per this protocol (e.g. at the MCS), or shall accept
messages from underlying entities and transfer it to the related
communication hardware for further action (transmission &
reception). For faithful management of messages at either end, the
Communication Controller shall run a Scheduler which will
maintain Queue Handlers, such as: Input Queue Handler,
Feedback Queue Handler, Output Tx Queue Handler, Output Rx
Queue Handler, Alarm Queue Handler & Reply Queue Handler.

2.3.1 Queue Management at MCS Segment

The MCS Communication Scheduler shall primarily be interfaced
to a Human Machine Interface (HMI) on one side and
Communication Hardware on the other side. The scheduler itself
shall run five set of Queue Handlers, namely Input Queue Handler,
Feedback Queue Handler, Output Tx Queue Handler, Output Rx
Queue Handler & Reply Queue Handler as shown in figure below:
Man
Machine
Interface

Communication
Interface

Queue Handler without making any entry in the Feedback Queue

Handler. As soon as the entry is made in the Output Queue
Handler, the particular message is cleared from the Input Queue
Handler.
C. The Output Tx Queue Handler sets the Packet Type field, (i.e.
single/multiple packet or retransmit packet) and also sets the
message information field (i.e. forward/reverse message) in the
message attribute field of message structure. Now this message is
transferred to the underlying communication hardware for
transmission and the scheduler waits for a particular duration of
time to receive the acknowledgement message (whether positive or
negative) from the UGV. This time duration is user settable and is
implementation dependent.
C.1 If nothing is received at Output Rx Queue Handler within that
time duration, then the current entry is retained in the Output
Tx Queue Handler. Now, the Packet Type field is set to
retransmit and the current message is transmitted for the
second time. If still, nothing is received till that duration, the
current message is transmitted for the third and last time. If
still nothing is received for that particular duration, the current
entry is cleared from the Output Tx Queue Handler and
appropriate information if conveyed to the HMI.
C.2 If a message is received within the time duration at the Output
Rx Queue Handler, then an error-check is performed on it. If
the error-check is incorrect i.e. the packet is received with an
error, then the current message is retransmitted with the
Packet Type field set to retransmit and the corresponding
message entry is retained in the Output Tx Queue Handler and
the process given at C.1 onwards is followed.
C.3 If the error-check is correct i.e. the packet is received without
an error, but a negative acknowledgement is received at
Output Rx Queue Handler then the current message is
retransmitted with the Packet Type field is set to retransmit
and the corresponding message entry is retained in the Output
Tx Queue Handler. If nothing is received for that duration,
then Step 3.1 is followed. If a negative acknowledgement is
received for the second time, then again the current message
is retransmitted with the Packet Type field set to retransmit
and the corresponding message entry is retained in the Output
Tx Queue Handler. Again, if nothing is received till the
duration, then Step C.1 is followed. If a negative
acknowledgement is received for the third and last time, then
the current entry is cleared from the Output Tx Queue
Handler and appropriate information if conveyed to the HMI.
C.4 If the error-check is positive i.e. the packet is received without
an error, and a positive acknowledgement is received at
Output Rx Queue Handler, then it is checked for the message
information field in message attributes.

Figure 3. Message Management at MCS

C.4.1

The queue management and message flow is discussed below:

A. The messages generated by several input devices are received
by the Scheduler at the HMI and kept in the Input Queue Handler.
B. If the message expects a feedback, an entry is made in the
Feedback Queue Handler and the message is transferred to the
Output Tx Queue Handler for further action. If the message does
not expect a feedback, then it is directly transferred to the Output

C.4.2

If the message information field shows positive

acknowledgement, then the particular message entry is
immediately cleared from the Output Tx Queue Handler.
If the message information field shows positive
acknowledgement with Feedback Queue Handler
populated at the receiver, then the current entry is
cleared from the Output Tx Queue Handler, a
GET_FEEDBACK_QUEUE_ENTRY
message
is
generated by the scheduler and entered into the Output
Tx Queue Handler at current position. Now the current

message is transmitted and this entry is retained at the

Output Tx Queue Handler.
i.

If nothing is received for particular time duration, then

Step C.1 is followed.

ii.

If a negative acknowledgement is received, then Step C.2

is
followed
by
transmitting
GET_FEEDBACK_QUEUE_ENTRY message again.

iii.

If a positive acknowledgement message with feedback

parameters is received, then the message is processed
and checked for correctness through error-check
verification. If error-check is correct, then a
FEEDBACK_PARAMETERS_RECEIVED message is
sent to the receiver, the corresponding message entry is
cleared from the Output Tx Queue Handler and
Feedback Queue Handler; and the parameters are passed
to the concerned output device through Reply Queue
Handler. If error-check is wrong, then again
GET_FEEDBACK_QUEUE_ENTRY
message
is
transmitted as per Step C.2.

C.4.3

If the message information field shows positive

acknowledgement with Alarm Queue Handler populated
at the receiver, then the current entry is cleared from the
Output
Tx
Queue
Handler,
a
GET_ALARM_QUEUE_ENTRY message is generated
by the scheduler and entered into the Output Tx Queue
Handler at current position. Now the current message is
transmitted and this entry is retained at the Output Tx
Queue Handler.

2.3.2

Queue Management at UGV Segment

The UGV Communication Scheduler shall reside inside Vehicle

Communication Module (VXM) at the UGV and primarily be
interfaced to Communication Hardware on one side and underlying
entities on the other side. The scheduler shall run six set of Queue
Handlers, namely Input Queue Handler, Feedback Queue Handler,
Output Tx Queue Handler, Output Rx Queue Handler, Alarm
Queue Handler & Reply Queue Handler as shown in figure below:

Figure 4. Message Management at UGV

The queue management and message flow is discussed below:
A. The messages received through the communication hardware
are entered into the Input Queue Handler.

i.

If nothing is received for particular time duration, then

Step C.1 is followed.

B. The current message is first checked for error-check

verification. If error-check is found incorrect, then the same
message is sent to Reply Queue Handler, for transmitting it back to
the transmitter with message information field set to NACK, and
the current message entry is cleared from the Input Queue.

ii.

If a negative acknowledgement is received, then Step C.2

is
followed
by
transmitting
GET_ALARM_QUEUE_ENTRY message again.

C. If error-check is found correct, then the same message is

examined for the DST GROUP ID, DST TYPE ID, DST CLASS
ID, DST RANK ID and DST INDIVIDUAL ID.

iii.

If a positive acknowledgement message with alarm

parameters is received, then the message is processed
and checked for correctness through error-check
verification. If error-check is correct, then an
ALARM_PARAMETERS_RECEIVED message is sent
to the receiver, the corresponding message entry is
cleared from the Output Tx Queue Handler; and the
parameters are passed to the concerned output device
through Reply Queue Handler. If error-check is wrong,
then again GET_ALARM_QUEUE_ENTRY message is
transmitted as per Step C.2

C.1 If the DST IDs are found incorrect i.e. message is not
intended for this UGV, then the current message entry is
immediately cleared from the Input Queue.

D.

The Reply Queue Handler transfers the feedback / alarm

parameters to the concerned Output Device Handler and
refreshes the queue entry as soon as the current message is
processed and acknowledged by the respective output device.

E. The unserviced Feedback Queue Handler entries shall be

refreshed in timeouts managed as per individual timers set with
the respective message entries.

C.2 If the DST IDs are found correct i.e. message is intended for
this UGV, then the current message is examined for SRC
RANK ID. If the SRC RANK ID < DST RANK ID i.e.
logical hierarchy of sender (Master) is lesser than that of
receiver (UGV), then no action is taken on the current
message and the current entry is cleared from the Input
Queue. If SRC RANK ID > DST RANK ID i.e. logical
hierarchy of sender (Master) is greater than that of receiver
(UGV), then the message is checked for Message Status field
in message attributes i.e. whether feedback is expected for this
message or not.
C.3 If Message Status field indicates feedback expected, then an
entry is made in Feedback Queue Handler and the message is
sent to the Output Tx Queue Handler, from where it is routed
to the underlying entities via Vehicle Control Module.
Otherwise, if the Message status field indicates no feedback
expected, then the message is directly sent to the Output Tx
Queue Handler. In any case, an entry is made into the Reply

Queue Handler for transmitting a positive ACK back to the

transmitter and corresponding entry is cleared from the Input
Queue Handler. The Feedback/Alarm Queue Handler status is
also embedded into the current ACK or NACK message by
setting the status bit in field i.e. whether Feedback or Alarm
Queue populated at UGV.
C.4 As soon as an entity gets ready with any Alarm or Feedback,
it informs the Vehicle Control Module and this entry is made
into the Output Rx Queue Handler.
C.4.1

C.4.2

If the entry is a feedback, then it is marked in the

Feedback Queue Handler, and the message is transferred
to the Reply Queue Handler. The Reply Queue Handler
informs the MCS about pending feedback by setting the
message status field i.e. Feedback Queue populated at
UGV. Once a GET_FEEDBACK_QUEUE_ENTRY
message is received from MCS in response to this
indication, the feedback details pertaining to the current
entry (or all feedback entries till now depending upon
the ARQ Scheme implementation) are sent back to the
transmitter by sending a positive acknowledgement and
appending the information in the parameter field. Now if
the next message which arrives after positive error-check
is FEEDBACK_PARAMETERS_RECEIVED then
entries are cleared from the Feedback Queue Handler
otherwise step C.4.1 is repeated.
If the entry is an alarm, then it is marked in the Alarm
Queue Handler, and the message is transferred to the
Reply Queue Handler. The Reply Queue Handler
informs the MCS about pending alarm by setting the
message status field i.e. Alarm Queue populated at UGV.
Once a GET_ALARM_QUEUE_ENTRY message is
received in response to this indication, the alarm details
pertaining to the current entry (or all alarm entries till
now depending upon the ARQ Scheme implementation)
are sent back to the transmitter by sending a positive
acknowledgement and appending the information in the
parameter field. Now if the next message which arrives
after
positive
CRC
check
is
ALARM_PARAMETERS_RECEIVED then the entries
are cleared from the Alarm Queue Handler otherwise
step C.4.2 is repeated.

3. REALIZATION OF SYSTEM
Communication Software Protocol implementation is divided in
two segments MCS segment and UGV segment as described in
previous section. The above design is realised onto
Communication Controller hardware (an embedded computation
system). For present consideration, the Communication Controller
is realized onto a PC104 based Single Board Computer. The
Communication Controller at MCS segment (HMI_CC) is loaded
with the HMI_Communication Controller Software Application
which is responsible for message formation and management at
MCS. Similarly at the UGV end Communication Controller
(VXM_CC) is loaded with the VXM_Communication Controller
Software Application which performs the job of message
management through several queues and communicates with the
different modules of the unmanned platform. The figure below
elaborates the scheme of CSP implementation.

Figure 5. Implementation Scheme for CSP at MCS & UGV

segments
The above softwares are designed to assure faithful
communication of messages between the MCS and UGV in real
time. Hence the CSP Software is divided into two parts as follows
and explained above:
i.
ii.

HMI Communication Controller (HMI_CC) Application:

This is the MCS part of CSP Software and it resides on the
HMI CC.
VXM
Communication
Controller
(VXM_CC)
Application: This is the UGV part of CSP Software and it
resides on the VXM CC.

The hardware details of the HMI CC (Human Machine Interface

Communication Controller) and VXM
CC (Vehicle
Communication Module Communication Controller) are presented
in the following section. The HMI CC and VXM CC Applications
are realised on QNX Real Time Operating System (Ver. 6.3).
The hardware specifications of both Communication Controllers
(used as either HMI_CC or VXM_CC) are as follows:
Table 1.Hardware Specifications of Communication Controller
CPU
System Chipset
Memory
VGA Port
Ethernet Port
RS-232 ports
RS-422/485 ports
USB 2.0
IDE
PS2
Expansion
SSD
Power Supply
Enclosure Dim.

AMD GX466 @ 333MHz

AMD CS5536
256MB, DDR266, SODIMM
Yes
RTL8100C for 10/100 Mbps
6 Nos.
1 No
2 Nos.
1 No.
KBD, MSE
PC/104
CFII Module (2GB)
12 / 24 VDC
200(W) x 120(D) x 75(H) mm

are provided in the following section. The test setup for this
independent testing is given as follows:

Figure 6. Communication Controller - Hardware

4. TESTING & VALIDATION

The communication over the wireless medium for command and
control of UGVs via MCS needs to be efficient in terms of
bandwidth, latency and signal propagation[4]. The signal
propagation is dependent on area of usage (urban or cross country)
as well as terrain conditions. The testing of above stated
communication methodology was carried out to determine the
efficiency in terms of throughput and latency[7]. Validation is
carried out through integrated testing of the communication
software. Communication Simulators have been designed and
realized which allow for message creation, formatting, sequencing
and testing at both UGV and MCS ends. The Test Setups (for SIL
& HIL testing) are described in the following section. CSP
modules at either ends are verified for following operational
parameters:

Throughput - Average rate of successful message delivery

over the communication channel measured in packets per
second (pkts/sec) (Quantitative analysis)

Latency To measure the Turn-Around Delay for a particular

message packet to reach to UGV segment and receiving its
acknowledgement at the MCS segment. (Quantitative
analysis)

The ideal value for Throughput is 18 to 20 Hz and that for Latency

is 50 to 56 ms. These values are derived with the standard update
rates for Digital Display devices for jerk-free motion display of
video frames. Since the human operator at the HMI is interacting
with the unmanned system therefore the seamless information
should be available to him at the MCS display in real time at above
rates.

Figure 7. Test set-up for SIL Testing

a.
b.
c.
d.
e.
f.

HMI_COMSIM as Windows utility on Windows-PC-1

VXM_COMSIM as Windows utility on Windows-PC-2
HMI_CPH as QNX Application on HMI_CC
VXM_CPH as QNX Application on VXM_CC
8-port 100Mbps LAN Switch (3COM, Linksys, CISCO) 2
nos
Wireless Modems (unmanaged bridge)

4.1.1 Design of HMI Communication Simulator

HMI_COMSIM is designed to assist the CSP developer by
providing MCS like functionality. It allows user to formulate, send
Messages (Commands, Queries) and receive Acknowledgements
which are logged for analysis. Sequential message transmission is
facilitated with the help of command scripts; which help in
generating test conditions for UGV end of communications.
Features of HMI_COMMSIM
Formulate new Commands and Queries
View Command and Queries.
Send Messages either periodically or on demand.
View and Log the Sent/ Received messages.
Generate snapshot of selected messages.
Receive pending feedback and alarms.
Generate or Run Command Scripts.
View received Dashboard Parameters.
Create View communication snapshots.
Run Communication and Load test.

4.1.2 Design of VXM Communication Simulator

4.1 Software-in-Loop Testing

The CSP application resides on two Communication Controllers
one each at the MCS end and the UGV end, i.e. HMI_CC &
VXM_CC respectively. These controllers and the corresponding
software applications can be independently tested without
connecting them to the various modules on-board MCS and
modules on-board UGV. For this independent testing, two
simulators are built in order to emulate the performances of the
modules on-board MCS such as Human-Machine Interface, Data
Archival & Playback etc. and modules on-board UGV such as
Vehicle Actuation Module, Vehicle Localization Module, Vehicle
Payload Module etc. These simulator applications are named as
HMI_COMSIM
(HMI Communication
Simulator) and
VXM_COMSIM (VXM Communication Simulator). The details

VXM_COMSIM is designed to assist the CSP developer by

providing UGV like functionality. It allows user to test UGV side
response by sending and receiving messages. Messages and
responses are logged for analysis. You may raise Alarms and
different feedback parameters for testing. Dashboard parameter list
is picked from a configuration file which will be sent as data with
heartbeat acknowledgements.
Features of VXM_COMMSIM
View messages.
Raise Alarms.
Dashboard Parameters configuration for heartbeat
acknowledgement data.

 View and Log the Sent/ Received messages.

Generate snapshot of selected messages.
Start/ Stop acknowledge useful for retransmission testing.
Send Wrong Transaction ID in message acknowledgements.

4.2 Hardware-in-Loop Testing

The CSP design scheme discussed above has been implemented,
verified & validated successfully on an actual target platform
(UGV) i.e. Honda CRV commercial automobile. This work was
carried out as a part of Indo-Singapore Collaboration in the field of
Robotics & Unmanned Systems wherein under Phase 1 of
collaboration, DRDO-India & DRTech-Singapore have jointly
developed enabling technologies for Autonomous Unmanned
Ground Vehicles. Under this phase, DRDO has successfully
demonstrated tele-operation of the target platform, which was
suitably modified by Driveby-Wire mechanism for remote.
Vehicle Actuation Module (VAM) related messages pertaining to
UGV related motion i.e. move at given throttle, given steering
angle, brake amount etc., were used for the tele-operation through
CSP modules. For verification and validation of above scheme,
tele-operation inputs were generated by human operator at
Operator Control Unit as shown in figure below. These inputs were
converted into tele-operation messages as per CSP by HMI
Communication Controller (HMI CC) and sent over wireless
media through communication hardware. At the UGV end the
messages received by the VXM Communication Controller via
communication hardware were interfaced with the Drive-by-Wire
mechanism controlled by the VAM on target platform (Honda
CRV).

CISCO 1300 Series Wireless LAN Access Point

Average Pkt
Standard
Average
Standard
Rate
Deviation
Latency
Deviation
(pkts/sec)
(pkts/sec)
(ms)
(ms)
13.034
0.252
76.718
1.489
RADIOLINX RLX-IH Industrial Hotspot
Average Pkt
Standard
Average
Standard
Rate
Deviation
Latency
Deviation
(pkts/sec)
(pkts/sec)
(ms)
(ms)
14.086
0.133
70.996
0.699
SmartSight S4100 Outdoor Multiband Transmitter /Receiver
Average Pkt
Standard
Average
Standard
Rate
Deviation
Latency
Deviation
(pkts/sec)
(pkts/sec)
(ms)
(ms)
14.644
0.291
68.28
1.343
The above test results show that the best Average Update Rate or
Throughput achieved is 14.644 pkts/sec and best Average Latency
achieved is 68.28 ms with the third case. These values are close to
the ideal values for Throughput i.e. 18 to 20 Hz and that for
Latency i.e. 50 to 56 ms. However, quantitatively the performance
index of Communication Software Protocol presented in this paper
is 81.36% which is calculated as follows:
Performance Index = Throughput achieved experimentally x 100
Ideal Throughput
The CSP design presented in this paper can be further enhanced by
implementing on multiple UGVs working simultaneously in
collaborative mode. Also, the throughput and latency values may
be further examined with newer communication hardwares with
better maximum burst rates e.g. IEEE 802.11n etc.

5. CONCLUSION

Figure 10. Test set-up for HIL Testing

4.3 Test Results

The performance tests were conducted for the HMI CC & VXM
CC as per test setup discussed above. The following wireless
modems were utilized for conducting the HIL tests.
Case 1 - CISCO 1300 Series Wireless LAN Access Point
Case 2 - RADIOLINX RLX-IH Industrial Hotspot
Case 3 - SmartSight S4100 Outdoor Multiband Transmitter
/Receiver
All of the above wireless modems are compliant to IEEE
802.11b/g with maximum burst rate of up to 54 Mbps. After
performing the test multiple times, the statistical average values for
Turn-around time and Throughput were logged at
HMI_COMSIM which are presented as follows:

The messaging protocol designed and realized provides a backbone

for communication between MCS and UGV and also between
UGVs. The protocol has been conceptualised keeping in mind
group behaviour and hierarchical control. The protocol has been
realised on a RTOS platform and the performance have been
verified and validated by conducting SIL and HIL testing. The test
results have been discussed and yields that the message structure,
size and formation has been optimally designed for
communication.

6. ACKNOWLEDGEMENT
The authors would like to thank Dr. S Guruprasad, Director,
R&DE(Engrs) and Shri. A K Patel, Group Director ASG-Robotics,
R&DE(Engrs) for all the encouragement and moral support in
carrying out this work. Also the help of Robotics group is deeply
acknowledged. The authors are thankful to R&DE(Engrs) where
this work is carried out. The authors are grateful to the anonymous
referees for their valuable comments and suggestions by which
paper becomes much clearer.

7. REFERENCES
[1] James A Wineefeld and Frank Kendal, Unmanned Systems
Integrated Roadmap, FY 2011-2036, Ref No 11-S-3613, Page
28, 32, 35
[2] Jorgen Pederson, Nov 2007, Interoperability Standards
Analysis (ISA) A Report by Standards Committee of the
National Defense Industry Association (NDIA) Robotics
Division, Page 6, 7
[3] James R Clapper, John J Young, Dec2007,Unmanned Systems
Roadmap 2007-2032, Dec 2007, Page 50
[4] Robotic Systems Joint Project Office, July 2011, Unmanned
Ground Systems Roadmap, Page 23
[5]

Jorgen Pedersen, May 2006, A Practical View and Future

Look at JAUS, White Paper, Page 3

[6] NATO Standardization Agency, SEPTEMBER 2005, NATO

Intelligence, Surveillance, and Reconnaissance (ISR)
Interoperability Architecture (NIIA), VOLUME 1:
Architecture Description, AEDP-2 (Edition 1) Page 13
[7] Daniel Jackson, Research and Component Systems of
Unmanned Ground Vehicles: A Survey, University of
Northern Iowa 11014, Bluff Street, Cedar Falls, IA 50613,
Page 2