A REMOTE CONTROL SYSTEM FOR TELEOPERATION

OF A SKID-STEER LOADER OVER A MOBILE WI-FI

MESH NETWORK

by
Christopher J. Meehan
 A thesis submitted to the Faculty and the Board of Trustees of the Colorado
School of Mines in partial fulfillment of the requirements for the degree of Master of
Science (Engineering).

Golden, Colorado
Date

Signed:
Christopher J. Meehan

Signed:
Dr. Kevin L. Moore
Thesis Advisor

Golden, Colorado
Date

Signed:
Dr. Kevin L. Moore
Professor and Head
Department of Engineering

ii
 ABSTRACT

Emergency situations, such as mine rescue operations, would benefit significantly

from the use of teleoperated vehicles. However, in an underground mine the envi-
ronment is not well suited for conventional teleoperation because the high frequency
wireless signals required for real-time video are strongly attenuated. One solution is
to provide a highly redundant network backbone, composed of many wireless nodes,
to relay information throughout the environment. Additionally, it is desirable that
such a network be flexible and mobile, so it could adapt to reach unconnected areas
and redistribute network load. In this thesis, we propose and implement a highly
capable mobile wireless network system composed of third-party Wireless-Fidelity
(Wi-Fi) mesh radios atop custom-built mobile robotic platforms. We also detail the
conversion of a Bobcat skid-steer loader into a wireless-network capable teleoper-
ated vehicle for use in an underground non-line-of-sight teleoperation scenario. The
thesis will cover the design, implementation, and evaluation of the wireless network
backbone and teleoperated remote control system for a Bobcat skid-steer loader.

iii
 TABLE OF CONTENTS

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

CHAPTER 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 MineSENTRY Description . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 MineSENTRY Project Outline . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 MineSENTRY Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Thesis Objectives and Outline . . . . . . . . . . . . . . . . . . . . . . . . 3

CHAPTER 2 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Subterranean Environmental Challenges . . . . . . . . . . . . . . . . . . 7

2.2 Subterranean Radio Wave Propagation . . . . . . . . . . . . . . . . . . . 8

2.2.1 Radio Wave Propagation Mechanisms . . . . . . . . . . . . . . . . 8

2.2.2 Radio Signal Attenuation . . . . . . . . . . . . . . . . . . . . . .9

2.2.3 Waveguiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Robotic Rescue Efforts . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Wi-Fi for Robotics and Disasters . . . . . . . . . . . . . . . . . . . . . 13

2.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

CHAPTER 3 DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Original Bobcat Remote Control System . . . . . . . . . . . . . . . . . 17

3.2 Wireless Mesh Network Description . . . . . . . . . . . . . . . . . . . . 18

iv
 3.3 Bobcat Remote Control System Analysis . . . . . . . . . . . . . . . . . 19

3.3.1 Original Transmitter Analysis . . . . . . . . . . . . . . . . . . . 20

3.3.2 Original Receiver Analysis . . . . . . . . . . . . . . . . . . . . . 24

3.4 Design Solution Outline . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 Transmitter Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5.1 TX Physical Design . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.2 TX Software Description . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Receiver Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6.1 RX Physical Design . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.6.2 RX Software Description . . . . . . . . . . . . . . . . . . . . . . 34

3.7 Wire Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.8 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.9 Autonomous Mobile Radio (AMR) . . . . . . . . . . . . . . . . . . . . 37

3.9.1 Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.9.2 Radio Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CHAPTER 4 CONSTRUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 Transmitter Construction . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Microprocessor with Ethernet . . . . . . . . . . . . . . . . . . . 43

4.1.2 I2C Shift Register Board Joystick Interface . . . . . . . . . . . . 45

4.1.3 Microprocessor Interface Board . . . . . . . . . . . . . . . . . . 46

4.1.4 LCD Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.5 Wi-Fi Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

v
 4.2 Receiver Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Original Bobcat Mainboard . . . . . . . . . . . . . . . . . . . . 48

4.2.2 RX Microprocessor Interface Board . . . . . . . . . . . . . . . . 49

4.2.3 RX LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.4 Power Distribution Board . . . . . . . . . . . . . . . . . . . . . 51

4.2.5 Ethernet Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.6 Ethernet Webcam . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

CHAPTER 5 EXPERIMENTATION AND ANALYSIS . . . . . . . . . . . . . . 53

5.1 Rajant Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Hallway Signal Strength vs. Distance . . . . . . . . . . . . . . . 53

5.1.2 Edgar Mine Signal Strength vs. Distance . . . . . . . . . . . . . 54

5.1.3 Edgar Mine Signal Strength vs. Distance (Non-LOS) . . . . . . 56

5.1.4 Network Analysis/Evaluation . . . . . . . . . . . . . . . . . . . 57

5.2 AMR Signal Strength Navigation . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Human only Experiments . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 AMR RSS Positioning Without Wall Following . . . . . . . . . 60

5.2.3 Completely Autonomous AMR RSS Positioning . . . . . . . . . 61

5.2.4 AMR RSS Navigation Summary . . . . . . . . . . . . . . . . . . 62

5.3 Bobcat Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.1 Teleoperated Control . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.2 Time Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3.3 Bobcat Subterranean Navigation . . . . . . . . . . . . . . . . . 66

vi
 5.3.4 Bobcat Performance Analysis . . . . . . . . . . . . . . . . . . . 69

5.4 Complete System Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5 Complete System Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

CHAPTER 6 CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.1 Recommendations for Future Work . . . . . . . . . . . . . . . . . . . . 75

6.2 Implications of Research . . . . . . . . . . . . . . . . . . . . . . . . . . 75

REFERENCES CITED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

APPENDIX A - A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.1 Circuit Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.1.1 RX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.1.2 TX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

A.2 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A.2.1 Arduino Ethernet Shield library modification . . . . . . . . . . . 82

A.2.2 RX Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.2.3 TX Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.2.4 AMR Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.3 IP Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.4 Original Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A.5 Modified TX Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A.6 Modified RX Pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

vii
 LIST OF FIGURES

Figure 1.1 Rescue workers in a disaster area [1]. . . . . . . . . . . . . . . . . . . 2

Figure 1.2 Example disaster scenario. . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 2.1 Rayleigh probability density function. . . . . . . . . . . . . . . . . . 10

Figure 2.2 Sago rescue robot: Remotec ANDROS Wolverine [1]. . . . . . . . . 13

Figure 2.3 Crandall rescue robot: Inuktun custom robot. . . . . . . . . . . . . 14

Figure 3.1 Bobcat remote control system[2]. . . . . . . . . . . . . . . . . . . . 18

Figure 3.2 Rajant Breadcrumb ME2 [11]. . . . . . . . . . . . . . . . . . . . . . 19

Figure 3.3 Original remote control transmitter. . . . . . . . . . . . . . . . . . . 20

Figure 3.4 Original remote control block diagram. . . . . . . . . . . . . . . . . 21

Figure 3.5 Original transmitter main board. . . . . . . . . . . . . . . . . . . . 21

Figure 3.6 Joystick printed circuit board. . . . . . . . . . . . . . . . . . . . . . 22

Figure 3.7 Paddles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3.8 Main switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 3.9 Peripheral switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 3.10 Original receiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 3.11 Data interception point. . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 3.12 Overview of the entire network. . . . . . . . . . . . . . . . . . . . . 27

Figure 3.13 Transmitter overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 3.14 Transmitter controls [2]. . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 3.15 High speed signal from joysticks. . . . . . . . . . . . . . . . . . . . . 29

Figure 3.16 Block diagram of I2C shift register circuit. . . . . . . . . . . . . . . 30

viii
Figure 3.17 Software flowchart for the transmitter. . . . . . . . . . . . . . . . . 31

Figure 3.18 Equipment placement on Bobcat. . . . . . . . . . . . . . . . . . . . 32

Figure 3.19 Outline of receiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 3.20 Software flowchart for the receiver. . . . . . . . . . . . . . . . . . . 35

Figure 3.21 TX RX microprocessor communication protocol. . . . . . . . . . . . 36

Figure 3.22 AMR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 3.23 AMR steering actuation. . . . . . . . . . . . . . . . . . . . . . . . . 38

Figure 3.24 AMR block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figure 3.25 Computing areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Figure 3.26 AMR sonar sensor configuration. . . . . . . . . . . . . . . . . . . . 40

Figure 3.27 AMR proximity sensors. . . . . . . . . . . . . . . . . . . . . . . . . 40

Figure 3.28 Software flowchart for collecting signal strength data. . . . . . . . . 41

Figure 4.1 Open view of transmitter circuitry. . . . . . . . . . . . . . . . . . . 44

Figure 4.2 Microprocessor with Ethernet capability. . . . . . . . . . . . . . . . 45

Figure 4.3 I2C shift register boards. . . . . . . . . . . . . . . . . . . . . . . . . 46

Figure 4.4 Microprocessor interface board. . . . . . . . . . . . . . . . . . . . . 47

Figure 4.5 Transmitter LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Figure 4.6 Transmitter Wi-Fi module. . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 4.7 Standard webcam for video feedback. . . . . . . . . . . . . . . . . . 49

Figure 4.8 Original Bobcat remote mainboard. . . . . . . . . . . . . . . . . . . 49

Figure 4.9 RX microprocessor interface board. . . . . . . . . . . . . . . . . . . 50

Figure 4.10 Receiver LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figure 4.11 Power distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

ix
Figure 4.12 Ethernet hub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figure 4.13 Standard webcam for video feedback. . . . . . . . . . . . . . . . . . 52

Figure 5.1 Signal strength vs. distance. . . . . . . . . . . . . . . . . . . . . . . 54

Figure 5.2 Map of the Edgar mine in Idaho Springs, CO. . . . . . . . . . . . . 55

Figure 5.3 Signal strength vs. distance. . . . . . . . . . . . . . . . . . . . . . . 56

Figure 5.4 Miami non LOS branch. . . . . . . . . . . . . . . . . . . . . . . . . 57

Figure 5.5 Signal strength vs. distance. . . . . . . . . . . . . . . . . . . . . . . 57

Figure 5.6 Computer commanded RSS following with a human in the loop. . . 59

Figure 5.7 Computer commanded RSS following with two humans in the loop. 59

Figure 5.8 Semi autonomous RSS positioning plot. . . . . . . . . . . . . . . . . 60

Figure 5.9 Corresponding semi autonomous RSS positioning map. . . . . . . . 61

Figure 5.10 Autonomous RSS positioning plot. . . . . . . . . . . . . . . . . . . . 62

Figure 5.11 Corresponding autonomous RSS positioning map. . . . . . . . . . . 62

Figure 5.12 Bobcat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Figure 5.13 Teleoperation testing. . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figure 5.14 Teleoperated network delay. . . . . . . . . . . . . . . . . . . . . . . 65

Figure 5.15 Bobcat underground. . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 5.16 Base station control. . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figure 5.17 Bobcat teleop. field of view. . . . . . . . . . . . . . . . . . . . . . . 67

Figure 5.18 Bobcat test: AMR RSS data. . . . . . . . . . . . . . . . . . . . . . 68

Figure 5.19 Search and rescue caravan. . . . . . . . . . . . . . . . . . . . . . . . 69

Figure 5.20 Base station. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Figure 5.21 Test one. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

x
Figure 5.22 Test two. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Figure A.1 RX Interface Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Figure A.2 RX Power Distribution Board . . . . . . . . . . . . . . . . . . . . . 80

Figure A.3 TX Interface Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Figure A.4 Joystick I2C Interface Board . . . . . . . . . . . . . . . . . . . . . . 81

xi
 ACKNOWLEDGEMENTS

I would like to thank my advisor, Kevin Moore, for helping me through my grad-
uate studies and the thesis writing process. This thesis also would not have been
possible without the help and contributions from John Steele and John Scales. I also
want to thank Manoja Weiss for all her support, mentoring, and help throughout
graduate school.

xii
 CHAPTER 1
INTRODUCTION

The field of wireless communications and teleoperated robotics has grown rapidly
in the past decade. Today, teleoperated vehicles are used for many applications
including air- and ground-based search and rescue, work in hazardous material zones,
and remote site access, among others. There has always been a strong need for
teleoperated help in disaster zones and subterranean search and rescue, because of
the inherent danger to search and rescue personal. However, the current limitations
of subterranean search and rescue robots are evident from the past disasters at the
Sago, Crandall Canyon, and Pike River mines.

1.1 Motivation

In the event of an accident, an explosion, a cave in, or whenever safety is com-

promised within a subterranean mine, rescue operations may need to occur to save
the lives of victims. However, underground rescue missions are cumbersome, time
consuming, and dangerous. Rescue workers move slowly within an underground mine
because they carry heavy equipment and must verify the safety of each section inside
the mine before they can enter, just like the scene depicted in Figure 1.1. Often,
rescue workers cannot reach victims in time and may become victims themselves.
Because of this dangerous environment and the urgency to rescue victims there
is a great need to improve the speed and safety of rescue missions. Robotic systems
and teleoperated vehicles can provide additional help in these situations and provide
a means for keeping rescue workers safe. For example, teleoperated vehicles may be
used as scouts to verify the safety of a particular hazardous area before humans enter,
to search for victims, or to reestablish communications.

1
 Figure 1.1: Rescue workers in a disaster area [1].

1.2 MineSENTRY Description

Mine Safety and Rescue through Sensing Networks and Robotics Technology
(MineSENTRY) was a research project at the Colorado School of Mines (CSM),
funded through CSM’s Center for Automation, Robotics, and Distributed Intelli-
gence (CARDI) by NIOSH Grant # 1R01OH009612-01. MineSENTRY was an effort
to develop and deploy advanced technology solutions for safety and rescue in sub-
terranean environments, with a particular focus on technology development in two
areas: sensor and control networks for improving communications and predicting and
mitigating the effects of hazards in mining operations and robotic systems in mining
emergency response, search and rescue efforts, and mining automation.

1.3 MineSENTRY Project Outline

The intention of the MineSENTRY research project was to provide a proof-of-

concept for teleoperated control of a rugged vehicle in an underground environment,
while emphasizing the novel concept of an autonomously adaptable ad hoc/mesh wire-
less network for seamless teleoperation. In a mesh network each node is independently
capable and the network as a whole can be continuously reconfigured around broken
paths between nodes. The proof-of-concept involved modifying a Bobcat front-end

2
loader [2] to be teleoperated over a Wi-Fi mesh network and developing a set of au-
tonomous vehicles to act as wireless relay nodes. Testing was conducted at the Edgar
experimental mine, owned by CSM.

1.4 MineSENTRY Scenario

In the MineSENTRY example scenario, an accident occurs within an underground

mine and cuts off communication and access to multiple sections in the mine, as shown
in Figure 1.2. To accomplish a rescue effort in this scenario requires many system
components. Specifically, a teleoperated vehicle, a rescue worker base station, and
multiple robotic vehicles acting as wireless relays. Additionally, in the proposed sce-
nario the teleoperated vehicle is a Bobcat front-end loader. During the scenario,
rescue workers teleoperate a front-end loader over a mesh network to scout dangerous
areas, reestablish communications, find survivors, and possibly clear rubble. While
the teleoperated vehicle is performing its tasks, secondary autonomous vehicles wire-
lessly relay communications from the rescue worker base station to the teleoperated
vehicle and relocate themselves to maintain the best possible connection.

Figure 1.2: Example disaster scenario.

1.5 Thesis Objectives and Outline

The goals for this thesis include showing the MineSENTRY proof-of-concept for
mesh networked teleoperation in a subterranean mine and providing the documenta-
tion required so others can rebuild or extend upon the work done for this project. To

3
achieve these two goals, the thesis will include:
Background Information
In Chapter 2 the physics governing electromagnetic (EM) radiation is explained
with a particular focus on the propagation properties and EM characteristics of a
subterranean mine. In addition an examination of recent search and rescue efforts
using teleoperated robotics will be addressed along with robotic systems utilizing
Wi-Fi technology.
Design and Construction Process
In Chapter 3 the original wireless control system for the Bobcat front-end loader
is analyzed for potential use in a subterranean environment and shown why it must
be modified. The new Wi-Fi based mesh network is explained. The Bobcat remote
control system is reverse engineered and converted into a Ethernet compatible device
for use with an ad hoc wireless system. The design process for the conversion covers
hardware signal interception, microprocessor configuration and communication, Eth-
ernet network configuration, and how to convert the existing signals to comply with
existing Bobcat electronics. In Chapter 4 the construction of the design elements is
shown to create a better understanding of how the design process works.
Experimentation and Analysis
In Chapter 5 the first set of experiments performed verify the propagation char-
acteristics of Wi-Fi EM radiation described by Chapter 2. Secondly, several tests
are performed working the way up in complexity towards a complete mock rescue
scenario utilizing a teleoperated Bobcat front-end loader and an autonomous vehi-
cle acting as a wireless relay. The first few steps tested the Wi-Fi mesh network
and the ability to navigate by signal strength alone. Successive experiments tested
the autonomous actions of the follower vehicle and its ability to navigate by signal
strength and proximity sensors. The Bobcat was tested individually to showcase and
verify the safety features necessary for full testing. Lastly, all systems were tested

4
together to allow the Bobcat front-end loader to be seamlessly teleoperated far into
an underground mine with a autonomous relay vehicle behind it.
Conclusions
In Chapter 6 conclusions are made about the performance of the teleoperated
Bobcat front-end loader and its autonomous support vehicle. Recommendations for
future work are made and comments are given to discuss how the technology devel-
oped by this research could be incorporated into the mining industry.
Code and Diagrams
In Appendix A code, diagrams, and charts create a medium for simplified re-
construction or deconstruction of circuit boards and programs for the Bobcat remote
control system conversion. Code is also provided for the autonomous vehicle signal
strength navigation algorithm.
Note: This thesis will not include the documentation and the design process for the
autonomous vehicles used as wireless relays.

5
 CHAPTER 2
BACKGROUND

To understand and overcome the difficulties of this project, a thorough under-

standing of the subterranean mining environment is needed. This environment is
challenging not only because of its ability to destroy or disable vehicles but also be-
cause of the high attenuation of wireless signals. In this chapter, we will discuss the
physical challenges and the laws of physics that govern the communications and wire-
less propagation within an underground mine. Lastly, we will cover some of the past
work that has been done in the field of teleoperated robotics for search and rescue
within mines and also in the field of teleoperation with general Wi-Fi networks.

2.1 Subterranean Environmental Challenges

Underground mines are physically taxing environments. Any vehicle within a mine
will likely encounter rocky terrain, mud, and water on a regular basis and might even
encounter rock fall, fire, low oxygen, flooding, thick mud, smoke, etc. in an emergency
situation. It may be impossible to build a vehicle that can withstand all the worst
case scenarios of a rescue mission, but it minimally should be ruggedized for minor
collisions, high ground clearance, sufficient traction, and water proofing. In addition
to all the vehicle’s physical challenges, a very large communications problem exists
within subterranean passageways. In the past many search and rescue robots had
to use cables for high bandwidth communications and for high power consumption.
Today, wireless systems are at a point where it is feasible,using commercial radio
hardware, to communicate within a subterranean mine, but there are still significant
difficulties.

7
2.2 Subterranean Radio Wave Propagation

The propagation of wireless signals within an underground mine or tunnel depends

on many parameters including the cross-sectional shape of the mine, the composition
of the surrounding rock, the curvature of tunnels, the position of antennas, and the
signal frequency, among many others. In our project we use 802.11b/g Wi-Fi for the
high bandwidth communication that allows real time video for teleoperation. This
standard Wi-Fi protocol uses a frequency of 2.4 GHz (2.412 GHz for Ch 1), which
has a small, but not negligible wavelength (12.43 cm) in comparison to the dimension
of the mine (3 m to 10 m). This wavelength can by calculated from the relation

c 2.998 × 108
λ= = = 12.430cm. (2.1)
f 2.412GHz

2.2.1 Radio Wave Propagation Mechanisms

The three basic mechanisms that impact the propagation of radio waves are re-
flection, diffraction, and scattering [3].
Reflection occurs when an electromagnetic (EM) wave impinges upon an object
with dimensions that are much greater than the wavelength of the EM wave. Spec-
ularly reflected waves behave according to Snell’s law, where the incoming angle of
incidence is equal to the outgoing angle of reflection. A related mechanism is trans-
mission, where the non-reflected energy in the wave penetrates into a medium. In
the case of a subterranean tunnel, the amount of the radio wave that reflects and
the amount that transmits is governed by the the dielectric properties of air and the
surrounding rock, along with the angle of incidence.
Diffraction occurs when a wave impinges upon the edge of a larger object, and
creates secondary wavefronts to ultimately produce a bending effect of the original
wave according to Huygen’s Principle [4]. Diffraction allows the possibility of wireless
communications when an object blocks the line of sight between a transmitter and

8
receiver, depending on the geometry of the obstacle and the properties of the incident
wave.
Scattering is another important propagation mechanism and occurs when a wave
collides with an object that is physically smaller then the wavelength of the impeding
wave. This collision creates many low power waves, all propagating in random di-
rections. This is particularly important in a subterranean mining environment where
the walls are cut by explosions and mining tools, resulting in very jagged and random
surfaces. The jagged walls can be thought of as many small objects, each creating a
scattering surface for incoming waves.
The net effect of these three mechanisms on an radio wave inside a subterranean
tunnel can be complicated. As we shall see, these mechanisms can create attenuation,
bending around corners, and even concentrations of signal called waveguiding.

2.2.2 Radio Signal Attenuation

Radio waves lose power as they propagate from transmitter to the receiver. These
losses can be described by many models depending on distance from the transmitter
to receiver, the far field range of the transmitter, and the wavelength. These models
arise from theoretical equations, statistical models, and experimental adjustments.
In an open line-of-sight environment, radio waves encounter free space loss of
power from an isotropic transmitter to an isotropic receiver dependent upon Friis’
model for free space loss [3]

Pr λ2
P L(d) = = , (2.2)
Pt (4π)2 d2

where P L(d) is the path loss, Pt is the transmitted power, Pr is the received power,
λ is the wavelength, and d is the distance between the transmitter and receiver.
However, an underground mine is far from the ideal free space model and will re-
quire a more complicated modeling approach for describing path loss. A subterranean

9
mine is a tunnel with many jagged walls that create a multitude of scattering points.
These scattered waves propagate in all directions creating interference at every loca-
tion in the mine. This interference many be constructive or destructive depending
highly on the position of antennas. This interference is known as channel fading and
is typically described by statistical models such as Rayleigh or Rician probability
distributions. In a subterranean mine, previous work has shown that the short range
power fluctuations follow a Rayleigh distribution, [5]. where the Rayleigh Probability
Density Function(PDF) is characterized as

k −k2 /2σ2
f (k; σ) = e . (2.3)
σ2

The standard Rayleigh PDF for a few values of σ is shown in Figure 2.1

Figure 2.1: Rayleigh probability density function.

Using an inverse power function and empirical measurements we can describe the
median power loss relationship with the relation [5]

Pr hκ2 i
P L(d) = = n , (2.4)
Pt d

where P L(d) is the path loss, Pt is the transmitted power, Pr is the received power, d

10
is the distance between the transmitter and receiver, and hκ2 i is the median electric
field amplitude gain of the radio channel, where κ varies from point-to-point according
to a PDF like that shown in Figure 2.1 and described by Equation (2.3). Lastly the
path loss exponent n creates the inverse power function and is derived from empirical
measurements describing how fast energy is lost from the transmitter to receiver as
a function of distance. In free space, the path loss exponent is exactly two. In most
scattering environments, the statistically derived path loss exponent, “n,” is typically
above two but can be below two for subterranean tunnels, because of waveguiding
effects. Table 2.1 shows common measured path loss exponents and some path loss
exponents measured from the Edgar experimental mine [5].

Table 2.1: Path loss exponents for various environments.

Free Space/ Vacuum 2.0

City 3-6
Edgar mine straight tunnel 1.2 - 1.6
Edgar mine bent tunnel 2.9 - 3.3

2.2.3 Waveguiding

A waveguide is a pipe that focuses the energy of a spherical radiating source. This
focusing of energy is due to the reflection of EM radiation off the surrounding walls,
forcing the waves to bounce from wall to wall in a zig-zag pattern. Ultimately the
vast majority of the radiating energy is forced to propagate further into the hollow
pipe. The effectiveness of the waveguide is determined by the amount of reflectivity
it has, which is dependent on the dielectric constant and the smoothness of the walls,
relative to the wavelength of the EM radiation. Several measurements have been
taken to determine that many subterranean mines do exhibit waveguiding effects at
Wi-Fi frequencies [5]. When this occurs it places the path loss exponent below the
ideal value of two for free space. However, past research has shown the path loss

11
exponent reduces below two only for straight tunnel measurements. This is because
the waveguide effect needs shallow angles of reflection and the bending losses for for
sharp corners is very high. [5]

2.3 Robotic Rescue Efforts

There have been many endeavors to create robots suitable for search and rescue
purposes. Robots are typically built to specialize in a single purpose, and search
and rescue robots are no different. Snake robots have been designed for search and
rescue in hard to reach places, like the rubble of a collapsed building [6]. Larger
wheeled robots have been used to assist police and armed forces to seek out hostages
or victims in hostile buildings and other urban search and rescue locations. There
have even been a few attempts to use robots for search and rescue in subterranean
mining disasters.
For example, during the West Virginia Sago mining disaster in 2006, rescue work-
ers attempted to utilize a Remotec ANDROS Wolverine Robot, shown in Figure 2.2,
for search and rescue. This robot was designed for urban search and rescue and bomb
disposal, but had been modified for subterranean purposes. The 50 inch tall, 1200
pound robot had three cameras for navigation and surveillance, lighting, a manipu-
lator arm, air monitoring equipment, and up to 5000 ft of tethered cabling for data
transmission and power[1]. However, the robot at the Sago mine became immobilized
by mud and was no longer of assistance to the search and rescue team.
Another example was at the Crandall Canyon Mine in Utah where a mobile but
tethered robot built by Inuktun, shown in Figure 2.3, was sent down several vertical
boreholes to assess damage and look for victims. The robot was small, at about eight
inches wide, and used a tether for communications and power. It had two sets of
cameras; one fixed camera for guidance and another camera on a boom for greater
field of view and control.

12
 Figure 2.2: Sago rescue robot: Remotec ANDROS Wolverine [1].

The robot encountered many problems including several scenarios where it could not
move past obtrusions in the borehole and water and debris fouling the camera lenses.
Ultimately the cable was severed by a boulder upon retrieval and the mission was
abandoned. However, the robot did produce some useful information and workers
where able to look around and determine where collapses had occurred in one section
of the mine. Unfortunately, it did not find any victims [7].
Other examples include the World Trade Center and most recently the mining
disaster at the Pike River coal mine in Greymouth, New Zealand.

2.4 Wi-Fi for Robotics and Disasters

Wi-Fi is very popular because of its availability, adaptability, and low cost. A few
commercial companies even make toys that utilize Wi-Fi control and video feedback
for teleoperated control of mobile toys [8].
There has also been a lot of active research using Wi-Fi for control over many
vehicles and robotic systems, including in disaster scenarios and especially urban dis-
aster zones[9]. Wi-Fi has many benefits that would be practical for disaster zones

13
 Figure 2.3: Crandall rescue robot: Inuktun custom robot.

in which cables have been used in the past. Some benefits include already estab-
lished networks in urban zones and the benefits of not being tethered while still
having the bandwidth to stream video. Another active area of research is the use
of ad-hoc meshed Wi-Fi devices for rescue efforts. Many research systems alternate
between two Wi-Fi standards, 802.11a and 802.11g, to create a pseudo-meshing ef-
fect between wireless devices[10]. These pseudo-meshing systems are typically not as
robust as the products from commercial companies because commercially available
products can automatically adapt to changes in the environment and changes in net-
work configuration. In recent years commercially available Wi-Fi mesh products have
become available partially thanks to improved regulation of communications within
underground mines due to the Mine Improvement and New Emergency Response Act
(MINER Act) of 2006 from the Mine Safety and Health Administration (MSHA).
Wi-Fi has been one of the leading technologies that mining companies have placed
within mines thanks to the MINER Act. If the Wi-Fi architecture is already in place
inside a subterranean mine, then it is an extra resource for any search and rescue

14
robot in case of a disaster. In the MineSENTRY project we also chose to use Wi-Fi,
but in this case for a mobile mesh network rather than as a fixed infrastructure.

2.5 Conclusions

This chapter provided the necessary background information to understand the

physics governing the propagation of radio waves within an underground mine. This
chapter also took a look back at recent search and rescue efforts using teleoperated
robots, and many systems that utilize Wi-Fi technology. Ultimately this creates a
better understanding of the mining environment in terms of electromagnetic charac-
teristics and an understanding of the search and rescue challenges.

15
 CHAPTER 3
DESIGN

This chapter covers the design process for converting a commercial wireless Bobcat
front-end loader to a Wi-Fi/Ethernet compatible teleoperated vehicle. Along with the
conversion, this chapter discuses the Rajant Wi-Fi communication radios that were
chosen for the mesh network used in the MineSENTRY project, and some of the
design details of the Autonomous Mobile Radio (AMR).

3.1 Original Bobcat Remote Control System

Bobcat offers a remote control add-on for their line of front-end loader vehicles
shown in Figure 3.1(a). This remote control system is composed of a user inter-
face/transmitter unit and a receiver box. The receiver box plugs into a compatible
front-end loader and controls the vehicle via an onboard communications network.
The intended use of this system is for line-of-sight remote control, to protect the
driver in dangerous situations. An example can be seen in Figure 3.1(b).
The 2.4 GHz high frequency signal used by the Bobcat remote control system is
very highly attenuated around the corners of a subterranean tunnel. This is because
inside the corners of the mine there are extremely high bending losses, multifaceted
surfaces causing scattering, and a low coefficient of reflection for waves. A mesh or
ad hoc network is the only means for transmitting these high frequency waves far
into the mine. Unfortunately, the Bobcat remote control system is proprietary and
incompatible with Ethernet or Wi-Fi standards. Thus it was necessary to devise a
modification to the system so it would work over a mesh network.

17
 (a) Add-on kit.

(b) Operation.

Figure 3.1: Bobcat remote control system[2].

3.2 Wireless Mesh Network Description

In order to transmit high bandwidth real-time video streams over a wireless chan-
nel, the wavelength of the wireless signals needs to be small, on the order of hundreds
of megahertz. Equipment using the license free FCC band of 2.4 GHz is readily
available in many forms and would provide sufficient bandwidth for real time video.
The most adaptable, widely used, inexpensive, and useful equipment at 2.4 GHz uses
Wi-Fi and Ethernet technologies. Wi-Fi and Ethernet technology provides tremen-
dous control and easy adaptability without reinventing the wheel. However, gigahertz
frequencies do not propagate well within an underground mine. The wavelengths are

18
so small that not much diffraction occurs around corners. Thus an ad hoc network
is needed to relay information throughout the mine environment, especially around
corners. There are several network devices available for creating ad hoc networks but
they lack easy adaptability and meshing abilities. As described in Chapter 1, mesh-
ing is the ability for one device to connect to multiple devices and for those devices
to connect to multiple devices, creating a redundant network to pass information
around physical breaks in the network. The company Rajant focusses on providing
Wi-Fi technologies for mining environments. Figure 3.2 shows Rajant’s meshed Wi-Fi
node call the Breadcrumb ME2. It is a highly adaptable Wi-Fi node capable of true
meshing and autonomously adapting to almost any physical network configuration.

Figure 3.2: Rajant Breadcrumb ME2 [11].

3.3 Bobcat Remote Control System Analysis

The general description of the original Bobcat remote control system is simple. It
is a transmitter and a receiver that communicate over a wireless channel. However,
the wireless communication protocol is very complicated because it uses a propri-
etary frequency hopping spread-spectrum transmission medium centered at 2.4 GHz.
This type of protocol is designed to prevent unwanted interceptions. The line-of-sight
range of the remote control system is about 500 meters. After the signal is captured

19
at the receiver, the data is interpreted and transferred to the vehicle using a standard
automotive wired network (CAN Bus). In the following sections we detail the anal-
ysis of each module within the original transmitter and receiver from Bobcat. This
description is included for the completeness of documentation and because signifi-
cant time and analysis was invested to determine the details of the original Bobcat
transmitter and receiver. Hopefully the information here allows follow up work to be
easier and more efficient.

3.3.1 Original Transmitter Analysis

The original remote control transmitter from Bobcat, seen in Figure 3.3, was
designed by the company Omnex.

(a) Remote control transmitter. (b) Transmitter internal circuitry.

Figure 3.3: Original remote control transmitter.

The system is designed in a modular fashion using parts previously created by Omnex
and is similar to other remote control systems by Omnex. The original remote control
transmitter can be broken down into the Main Board, Joysticks, Paddle Controls,
Switches, and Indicators. The interface between all five of these modules can be seen
in Figure 3.4.

20
 Indicators Joysticks Paddles Switches

Main Board

Proprietary wireless transmission

Figure 3.4: Original remote control block diagram.

Main Board: The main board, shown in Figure 3.5, takes all the data from the
joysticks, paddles, and switches. It then processes this data on a microprocessor and
sends it to a one way RF transmitter, all on the same circuit board. In summation,
this board handles all the data collection and transmission.

Figure 3.5: Original transmitter main board.

Joysticks: The joysticks control the most important aspects of the front-end
loader. One controls the motion of the vehicle while the other controls the motion
of the bucket. The joysticks are Hall Effect based and have a microprocessor aboard
to capture the small analog signal and digitize it for transmission to the main board.
The microprocessor printed circuit board for the joystick is shown in Figure 3.6.

21
 Figure 3.6: Joystick printed circuit board.

Each joystick communicates with the main electronics board via a six pin con-
nector. The connector can be connected in a daisy chain so that only one connector
attaches to the main board. In the chain configuration all wires except the data out
are connected in parallel. The data out line for each joystick is passed into each
microprocessor down the chain where the last microprocessor transmits the data for
all the joysticks. This only happens once because there are only two joysticks.
The six pins correspond to:

Pin 1: + 9.6 V
Pin 2: N.A.
Pin 3: GND
Pin 4: Data out
Pin 5: Reference Pulse
Pin 6: Clock Pulse

The data out is a digital two’s complement pulse code modulation signal created
by a microprocessor on each joystick circuit. This data signal is triggered out by a
clock and reference pulse train that is provided by the main board via the six pin
connector.
Paddle Controls: The two paddles control the actuation of peripheral devices
that could be attached to the Bobcat front-end loader. The paddles are simple elec-

22
tronic devices and are each a pair of potentiometers. A single paddle shown attached
to the controller and removed is shown in Figure 3.7.

(a) Top. (b) Removed.

Figure 3.7: Paddles.

The paddles can be thought of as analog output devices. They connect to the main
board via a seven wire connector. The seven pins correspond to:

Pin 1: N.A.
Pin 2: 3.3 V Power
Pin 3: Analog out (0 to 3.3 V)
Pin 4: GND
Pin 5: N.A.
Pin 6: N.A.
Pin 7: 3.3 V Power

Switches: The Bobcat remote control has eight standard switches shown in Fig-
ure 3.8.

Figure 3.8: Main switches.

23
 Each switch is either a single pole single throw (SPST) or a single pull double
throw (SPDT). Each signal is digital, requiring either one or two bits each. Figure 3.9
shows two peripheral switches that differ from the other standard switches, however
their operation is the same. The emergency stop (E-stop) switch is a very critical
switch and is simply a single pull single throw switch. The ignition switch is a pair of
single pull single throw switches for turning on the remote and another for starting
the vehicle ignition.

(a) E-Stop (top). (b) E-Stop (bottom). (c) Ignition.

Figure 3.9: Peripheral switches.

Indicator Board: An indicator LED board is attached to the interior of the re-
mote. It provides LED indication for antenna connectivity, E-stop, and battery level.
An additional feature of this board is a tilt sensor which will trigger the emergency
stop in case the user falls over.

3.3.2 Original Receiver Analysis

The receiver box is a plug in module that can attach to most Bobcat loaders and
control it remotely. The actual electronics, shown in Figure 3.10(b), are stored inside
a ruggedized outer shell shown in Figure 3.10(a).
The receiver box controls the Bobcat vehicle through the wired J1939 CAN-Bus
network. The receiver has control over individual components of the vehicle with
this type of network. The specific J1939 CAN network is an extended version of the
original CAN-Bus, a protocol designed for vehicles. In the front-end loader network

24
 (a) Outer shell. (b) Interior electronics.

Figure 3.10: Original receiver.

Bobcat added several features to prevent theft and for general safety. Bobcat’s safety
features include the rapid changing of messages, which follow a encrypted pattern.
If any bit is not received at the correct time and in the correct pattern then the
vehicle shuts down. Reproducing these CAN-Bus messages with the correct pattern is
extremely difficult if not impossible. A month of work was dedicated to intercepting
the raw data, transferring it over a Ethernet/Wi-Fi network, and recreating these
CAN-Bus messages, to no avail. The extremely small time window did not leave room
for any errors during transfer, which occasionally happens with a wireless network.
More time was dedicated to interpreting and recreating simulated CAN-Bus messages
with a microprocessor, however, we were unable to crack the encrypted pattern and
did not receive any help from Bobcat or Omnex.

3.4 Design Solution Outline

In order to use the Rajant Wi-Fi mesh network, the Bobcat remote electronics
need to become Ethernet compatible. Figure 3.11 shows the best location to intercept
information is at the data input of the main board, in other words at the output of
the physical switches and joysticks.

25
 Figure 3.11: Data interception point.

Capturing data at this location is the only feasible option because intercepting
the original wireless signals or CAN-Bus networks are far too complicated. With
the following three steps the Bobcat front-end loader can be controlled using the old
electronics and the additional Wi-Fi network.

1.) Capture the data from the switches and joysticks on the shell of the remote.
2.) Transfer that data over the Wi-Fi/Ethernet network.
3.) Replicate the switch and joystick signals for the electronics that were in the
original Bobcat remote (keep the original remote electronics on the Bobcat).

Figure 3.12 shows the Ethernet/Wifi network layout for the search and rescue
caravan, the separation of Bobcat remote control components, and the integration of
Ethernet capable microprocessors.
The two Ethernet capable microprocessors are used to read and transfer the data
across the Wi-Fi/Ethernet network. A printed circuit board helps with level con-

26
 Figure 3.12: Overview of the entire network.

version and miscellaneous tasks for each microprocessor. One microprocessor reads
data from the switches, paddles, and joysticks and then transmits the data over the
Ethernet/Wi-Fi channel. The other microprocessor collects the data from the chan-
nel and reproduces it for the Bobcat transmitter mainboard. Each microprocessor
board is based upon the ATmega1280 and is commonly known as the Arduino Mega.
An add-on Ethernet board is attached to each microprocessor board. This Ethernet
board is commonly called the Arduino Ethernet-Shield and uses an SPI based W5100
Ethernet Chip.

3.5 Transmitter Design

The new transmitter only uses the shell of the old remote control transmitter from
Bobcat, but the electronic mainboard has been replaced by a microprocessor, a few
printed circuit boards, and a Wi-Fi access point, as depicted in Figure 3.13.
In the new transmitter the microprocessor and PCBs act to capture all the data
from the remote control shell, while the Wi-Fi access point is used to put the Ethernet
data onto the Rajant network wirelessly.

27
 Figure 3.13: Transmitter overview.

3.5.1 TX Physical Design

In order to read the data from all the switches, joysticks, and paddles several
custom electronics are employed. The switches and paddles are easy to read since the
switches are digital signals and the paddles are analog voltages. However, the joysticks
require additional circuitry to pass the data to the microprocessor. A breakdown of
the number of bits required to capture all the data from the Bobcat remote shell at
a single moment of time is seen in Figure 3.14.

Figure 3.14: Transmitter controls [2].

28
 The joysticks communicate with the main electronics board via a pulse code mod-
ulated data signal along with a trigger/reference line and clock line. Figure 3.15
shows all three signals with the reference signal in both and shown at different time
scales. The reference rising edge pulse starts the communication and the individual
clock pulses each trigger a single bit from the joystick PCB.

Figure 3.15: High speed signal from joysticks.

Another complication for reading the joysticks is that the pulses are too fast for
the digital port of the microprocessor since each pulse is only a few microseconds
in length. A way around this is to latch the data into a shift register and send
the collected data with a high speed data bus, specifically I2C. In order to get the
data out of the joysticks, a fake reference and clock signal need to be created by the
microprocessor. After the microprocessor sends this data it needs to read the data
captured in the shift register through the I2C communication line. The interaction
between the microprocessor, the I2C shift register board, and the joystick electronics
is shown in Figure 3.16
The I2C board receives the reference pulse, clock pulse, data from the joystick,
and a latch pulse. It then passes it through a shift register, latches this data after all
16 bits have occurred, then passes it to a parallel-to-I2C chip which sends the data
along the I2C data bus to the microprocessor.

29
 Figure 3.16: Block diagram of I2C shift register circuit.

Along with two I2C shift register boards (one for each joystick), there is one more
PCB for the Transmitter. This third PCB handles the following tasks:

1.) Isolation between microprocessor and Bobcat TX shell.

2.) Voltage level conversion between microprocessor and TX shell.
3.) Power conversion and distribution for all devices embedded in the shell.
4.) Indicator LED for power enabled.

3.5.2 TX Software Description

The software uses the Arduino development environment and utilizes the built-in
libraries for I2C communication and Ethernet communication. The program is split
into several sections: TCP/IP Ethernet communication, Digital I/O, 12 bit ADC, and
I2C Communication, clock, and trigger interrupts (output compare) for joystick data.
Figure 3.17 is a block diagram showing the interaction between code modules and the
flow of the program in general. The software first goes through an initialization period
where it configures the registers and starts the Ethernet and I2C communications.
The program then enters a loop where it performs tasks 1 through 3 and repeats.

30
 Figure 3.17: Software flowchart for the transmitter.

If the program fails to maintain a connection to the host, task 2, then it will purge
the connection and retry connecting. This sequencing is summarized as:

1.) Read the data from the switches, joysticks, and paddles.
2.) Verify the connection with the host.
3.) Send all the data to the host in a fixed pattern.

Task 1 utilizes the digital I/O to capture data from the switches, 12 bit ADC to read

31
the paddles, and captures latched data from the I2C boards over the I2C communi-
cations line.
Running independently of the main program is a interrupt-based set of functions
to provide real time feedback from the I2C board for the two joysticks. This interrupt
uses standard Output Compare to provide clock, trigger, and latch outputs for the
joysticks and shift register boards.

3.6 Receiver Design

The receiver microprocessor takes the data sent over the Wi-Fi/Ethernet net-
work. It then simulates the signals of the switches, paddles, and joysticks for the
original mainboard that was in the Bobcat remote. The original mainboard is now
physically located on the Bobcat, so there is a very short wireless jump between the
original Bobcat transmitter mainboard and the original Bobcat receiver, as shown in
Figure 3.18.

Figure 3.18: Equipment placement on Bobcat.

The microprocessor communicates with the original Bobcat TX mainboard through

a PCB circuit that converts voltage levels, distributes power, and digital-to-analog
conversion (DAC). Figure 3.19 shows the flow of information from the Wi-Fi/Ethernet
source to the Bobcat remote mainboard.

32
 Figure 3.19: Outline of receiver.

3.6.1 RX Physical Design

The PCB that acts as a buffer between the microprocessor and the original Bobcat
electronics was designed to provide all the miscellaneous tasks that could not be
provided by the microprocessor board. It is mainly composed of transistor array
chips which steps down the logic level voltage from 5V at the microprocessor to 3.3V
at the Bobcat electronics. LEDs also provide an easy interface to detect changes in
logic level for all the switch positions. A rather important note is the order of pull
up or pull down resistors for the logic level components on the Bobcat are oriented
to lock the parking brake and bucket of the Bobcat during a scenario with loss of
communication to the microprocessor. In order to simulate the analog voltages from
a paddle on the remote control, a DAC is required. Unfortunately, the microprocessor
does not include a DAC so one had to be added externally. This PCB includes a chip
that converts I2C serial data into analog voltages. Two of the analog pins where used
to simulate the two paddles on the remote control. Power distribution was also added
to this PCB at three voltage levels. The following voltages are provided:

1.) 9.0 V to power the original Bobcat electronics

2.) 5.0 V for microprocessor power and logic
3.) 3.3 V for the original Bobcat electronics logic

33
3.6.2 RX Software Description

The receiver microprocessor gathers all the control data from the TCP/IP channel
where it distributes that information across several areas including: digital I/O, an
analog I2C ADC, interrupt based joystick data simulation. The software starts out
in an initialization section, where all the ports are configured. It then passes to the
main loop where it looks for a client to connect to it. When it receives a connection
with a client, it goes into a second loop that that executes the following tasks:

Task 1.) Verify the connection with the client.

Task 2.) Collect data from the client according to a fixed pattern.
Task 3.) Pass the data along to the digital ports, I2C line, and output compare variables.

During task 2, the connection is verified a second time with a data stream that follows
a set pattern. First a pair of start bytes is sent, then nine bytes of data, then a pair of
stop bytes. If any of the patterns are incorrect, it is flagged and the number of errors
is incremented. If the pattern was correct the number of errors is nulled. Therefore,
after multiple errors have occurred sequentially, the program steps into one of several
safety stops.

Safety stage 1: 8 < Errors < 20 Stop bucket and wheels.

Safety stage 2: 20 < Errors < 30 Lock bucket and set parking brake.
Safety stage 3: 30 < Errors Shut down vehicle.

An output compare subroutine is always running independent of the main loops.

This subroutine takes the current variable for joystick data and triggers a pulse code
modulated signal with precision timing on a digital output pin of the microprocessor.
A full block diagram of the software is shown in Figure 3.20.

34
 Figure 3.20: Software flowchart for the receiver.

3.7 Wire Routing

Due to the large number of wires for the original Bobcat remote platform, there
needed to be a lot of cable routing from the shell electronics into the microprocessor.

35
The large number of cables can be daunting, but they are organized into sets each
with a labeling system outlined in Appendix A. Additionally, a map for the original
wiring system was kept in case the work needed to be undone. This wire map is also
found in Appendix A.

3.8 Communication Protocol

Figure 3.21 shows the transmission protocol between the host and the client mi-
croprocessors. This protocol has to match the following pattern that was created to
keep the microprocessors in phase with each other.

Figure 3.21: TX RX microprocessor communication protocol.

First, two start bytes are sent (-2,-2) to begin transmission, then nine bytes of data
are sent. To end the transmission two stop bytes are sent (-3,-3).If at anytime the
pattern is not matched the microprocessor throws out the data and tries again.

36
3.9 Autonomous Mobile Radio (AMR)

The AMR is an autonomous vehicle that carries a Rajant Wi-Fi node. This node
communicates with the vehicle telling it when and where to move based on radio
signal strength measurements. This section covers the software for the Rajant radio
communication interface and a summary of the vehicle hardware.

3.9.1 Vehicle

This section is included for context. Details of the systems described here are not
a contribution of this thesis. An EZ-GO TXT model golf cart, seen in Figure 3.22,
was chosen as the base platform of an autonomous mobile radio (AMR) because it is
a commercially ruggedized and reliable vehicle, the emission free electric motor, the
long lasting battery life, and the easily modifiable platform for electronic actuation.

Figure 3.22: AMR.

After acquiring the base platform, the golf cart was modified for electric actuation of
brakes, steering, and motor control. A showcase of the steering actuation can be seen
in Figure 3.23.
Secondly, microprocessors and a high level computer were added to provide low

37
 Figure 3.23: AMR steering actuation.

level control for vehicle control and high level control for sensor evaluation and au-
tonomous decisions. Figure 3.24 shows the hardware and low level microprocessor
interface.

Figure 3.24: AMR block diagram.

Figure 3.25 shows the microprocessor and computer for processing of data and vehicle
control, which is surrounded by a protective enclosure. The processor communicates

38
through the Rajant network through a central Ethernet hub, which also provides
connectivity for an Ethernet based camera.

(a) Rajant network hub.(b) Microprocessor and computer enclosure.

Figure 3.25: Computing areas.

Several proximity sensors were added to provide sufficient information to the low and
high level controllers for logical movement in tight environments. The sensor list
includes:

14x Maxbotix ultrasonic ranging sensors.

4x Sharp infrared ranging sensors.
4x Hall effect odometry sensors, 1 per wheel.
1x String potentiometer steering angle sensor.
1x Inertial measurement unit.

The ultrasonic sonar rangers are arranged in a pattern to provide a complete 360
degree field of view for smart autonomous decisions, as shown in Figure 3.26.
Figure 3.27 shows the placement of some of the ultrasonic sensors.
The full details about the description and development of the AMR can be found in
the M.S. theses of other MineSENTRY members [12], [13].

39
 Figure 3.26: AMR sonar sensor configuration.

(a) Front (b) Side

Figure 3.27: AMR proximity sensors.

3.9.2 Radio Navigation

In order to autonomously navigate within an underground mine, the AMR needs to

have information about the signal strength to the surrounding nodes. The properties
of the Rajant ME2 Breadcrumb Wi-Fi nodes can be accessed via a set of Java API
libraries. The only problem is the AMR navigation is based on the Python language.
The easiest way to get the data from Java to Python is a combination Java/Python
language called Jython. However, several Python libraries are incompatible with
Jython. The other alternative is to transfer data via a TCP socket from Java to
Python. To collect the necessary signal strength data, we wrote a pair of programs
that communicate over a TCP socket. The host program is written in Jython to

40
capture the data using a Java API and to transfer the data to a client over a TCP
socket. The client program receives the data from the host and constantly updates
variables for the main program (written in Python) which uses the signal strength
information. The flow of data from the Java server to python client subroutine to
python main program can be seen in Figure 3.28,

Figure 3.28: Software flowchart for collecting signal strength data.

3.10 Conclusions

In this chapter we explained the Bobcat remote control system and its limitations
within a subterranean mine. We then covered the Rajant Wi-Fi mesh network system
and performed a thorough reverse engineering analysis of the Bobcat remote control
system. Next we detailed the design for converting the Bobcat remote control system
to be Ethernet/Wi-Fi compatible. A brief summary of the AMR was also covered,
with an emphasis on the radio signal strength navigation. The following chapter
builds upon the design elements and covers the construction of the Bobcat remote
control to Ethernet/Wi-Fi conversion.

41
 CHAPTER 4
CONSTRUCTION

This chapter is an extension of the previous chapter and shows the construction
stages of all the electronic equipment required to convert the Bobcat front-end loader
to a teleoperated vehicle. Along with the Bobcat, there is also a description of the
final implementation of the AMR and Rajant Wi-Fi network.

4.1 Transmitter Construction

The modified transmitter, which can be seen in Figure 4.1, is composed of the
original shell with all its switches, the two paddles, and the two joysticks. The
following additions were made:

1.) A microprocessor with Ethernet abilities

2.) Two PCBs that convert the joystick data to I2C
3.) A power distribution and level conversion PCB
4.) A diagnostic LCD
5.) A Linksys Wi-Fi access point

4.1.1 Microprocessor with Ethernet

The microprocessor used is a common Arduino Mega board available from Spark-
fun.com (DEV-09152) [14]. This board uses the Atmega 1280 microprocessor, it has
54 digital I/O, one I2C, four UARTs, and a 16 MHz crystal. An Ethernet add on
called the Arduino Ethernet Shield allows the Arduino Mega board to connect to the
Rajant Ethernet/Wi-Fi network. The Ethernet shield is based on the Wiznet W5100
Ethernet chip providing connectivity through TCP or UDP.

43
 Figure 4.1: Open view of transmitter circuitry.

The Ethernet shield connects to the Arduino board using long pins which extend
through the shield. This keeps the pin layout intact and allows another shield to be
stacked on top. The Arduino Mega communicates with the Ethernet shield through
an SPI protocol.
Since the Ethernet Shield was not designed for the Arduino Mega, a slight mod-
ification is necessary to allow communication. Three of the four pins for SPI com-
munication on the Ethernet shield need to be rerouted to the correct location on the
Arduino shield. This is done by isolating the three wires (bending them away) and

44
using external jumpers to make the new connections which can be seen in Figure 4.2.
In addition to the hardware changes, changes in the software library are necessary to
reflect the pin rerouting (see Appendix A.2.1 [15]). The three pins were rerouted as
follows:

MEGA pin 50 (MISO) to Arduino Ethernet Shield pin 12.

MEGA pin 51 (MOSI) to Arduino Ethernet Shield pin 11.
MEGA pin 52 (SCK) to Arduino Ethernet Shield pin 13.

Figure 4.2: Microprocessor with Ethernet capability.

4.1.2 I2C Shift Register Board Joystick Interface

The I2C shift register board went through several revisions because of the com-
plicated wiring scheme. The three revisions can be seen in Figure 4.3. Ideally this
board would be miniaturized using a four-layer PCB because the number of traces
are very high and the need for vias is very great.

45
 (a) Rev 1.0.

(b) Rev 2.0.

(c) Rev 3.0.

Figure 4.3: I2C shift register boards.

4.1.3 Microprocessor Interface Board

This interface board, seen in Figure 4.4, translates voltage levels between the
microprocessor and joystick electronics, it also contains power regulation and an in-
dicator LED for ”Power ON” indication.

4.1.4 LCD Indicator

As seen in Figure 4.5, a standard 32 character LCD from SparkFun.com (LCD-

00709) was used to provide feedback to the user [14]. The LCD has an additional
backpack circuit from SparkFun.com (LCD-00258) that controls the LCD via serial

46
 Figure 4.4: Microprocessor interface board.

communication from the microprocessor [14]. The serial LCD controller was used to
save the digital I/O of the microprocessor for other purposes.

Figure 4.5: Transmitter LCD.

4.1.5 Wi-Fi Module

A standard Wi-Fi access point from Linksys (WAP54G) was used to provide
wireless connectivity from the microprocessor in the remote control shell to connect
to the Rajant Wi-Fi network. To save space, the device was disassembled and placed
within the base of the Bobcat remote control shell as seen in Figure 4.6.

47
 Figure 4.6: Transmitter Wi-Fi module.

4.2 Receiver Construction

The modified receiver, seen in Figure 4.7 is composed of seven components:

1.) The original electronic mainboard that was inside the Bobcat remote control.
2.) A microprocessor with Ethernet abilities.
3.) A microprocessor interface board.
4.) A diagnostic LCD.
5.) A power distribution board.
6.) An Ethernet hub.
7.) An Ethernet based webcam.

In addition, all the contents are protected by a plexiglass box, that can be installed
in the back window (or other feasible location) of the Bobcat.

4.2.1 Original Bobcat Mainboard

The mainboard, seen in Figure 4.8, was removed from the Bobcat original remote
control and placed in the new receiver. This board is the only means to communicate

48
 Figure 4.7: Standard webcam for video feedback.

with the original Bobcat Receiver, essentially controlling the Bobcat.

Figure 4.8: Original Bobcat remote mainboard.

4.2.2 RX Microprocessor Interface Board

Since the original Bobcat Mainboard runs on 3.3V logic and the microprocessor
runs at 5V, logic level conversion is needed on all the digital I/O pins and a few
other pins. A circuit board was created for this logic level conversion and is seen in
Figure 4.9. This board also provides an I2C DAC to simulate the paddles, LEDs for
debugging, and power regulation from 12V to the 3.3, 5V and 9.6V.

49
 Figure 4.9: RX microprocessor interface board.

4.2.3 RX LCD

Just as it is necessary to have an LCD on the transmitter, it is necessary to

have one on the receiver. The LCD seen in Figure 4.10 provides crucial debugging
information to the user, displaying status and errors.

Figure 4.10: Receiver LCD.

50
4.2.4 Power Distribution Board

Because of so many external peripherals (Rajant Breadcrumb, Ethernet cam.,

Ethernet hub, LCD, etc) an additional power regulation circuit is needed. This power
regulation and distribution board is seen in Figure 4.11.

Figure 4.11: Power distribution.

4.2.5 Ethernet Hub

Since the Bobcat can have multiple webcams and other Ethernet based devices, a
network hub is necessary to provide connectivity to all of these devices. A standard
Ethernet hub was used and can be seen in Figure 4.12.

Figure 4.12: Ethernet hub.

51
4.2.6 Ethernet Webcam

An Ethernet based webcam from Linksys, seen in Figure 4.13, provides the easiest
interface to the Rajant Ethernet/Wi-Fi network. A slight modification was made to
adjust the field of view, by adding two lenses to change the foci of the original optics.

Figure 4.13: Standard webcam for video feedback.

4.3 Conclusions

In this chapter we showed the constructed forms of the items described in Chapter
3 in addition to all the elements required to make the system work together. These
elements were shown to create a better understanding of how the design process works
and create a showcase for anyone intending to build upon the work already done on
this project.

52
 CHAPTER 5
EXPERIMENTATION AND ANALYSIS

In this chapter, the results of several tests of individual subsystems are shown to
establish a good idea of how the entire system will perform. These subsystems include
the Wi-Fi ad hoc Rajant network, the teleoperated Bobcat front-end loader, and the
autonomous mobile radio (AMR). In addition to each subsystem, the entire system
was tested to provide the final proof-of-concept and show the best comparison with
a real scenario. To achieve a direct correlation to a real subterranean environment,
several of the experiments took place underground in the Edgar experimental mine
in Idaho Springs, CO.

5.1 Rajant Network

Several experiments were designed and implemented to characterize the perfor-

mance of the Rajant network along with the propagation properties of Wi-Fi based
EM waves in a subterranean environment. The Rajant Breadcrumbs can output sig-
nal strength in terms of signal-to-noise ratio (SNR). In a underground mine, we can
make the assumption that noise levels will be equivalent throughout the environment
and thus the SNR will be dependent upon the signal strength and not the noise level.
Therefore SNR has a direct correlation with radio signal strength (RSS).

5.1.1 Hallway Signal Strength vs. Distance

To get an indication of how signal strength drops according to distance in a tunnel

environment, signal measurements were taken in a hallway. In Figure 5.1 twenty RSS
data points were gathered, averaged, and compared to corresponding distance points.

53
 Figure 5.1: Signal strength vs. distance.

The results from Figure 5.1 are highly dependent on the environment and show a
null at 60 ft because of a small obstruction. Nevertheless, the results follow a standard
exponential decay and provide a good control data set for the Rajant Wi-Fi devices.

5.1.2 Edgar Mine Signal Strength vs. Distance

We performed several experiments within the Edgar experimental mine to quantify

the distance verses signal strength for a few tunnels. We took tests of line-of-sight
(LOS) and non-LOS environments within the Miami and Army tunnel sections of the
mine. The two sections of the mine can be seen in Figure 5.2.
The experiments were performed using two Rajant ME2 BreadCrumb Wi-Fi
nodes, at a transmitter power of 34 dBm with omni-directional TX and RX antennas.
In the experiments the first node was placed at 0ft and the second node was placed
at several locations at varying distances from the first node. SNR was recorded at
several distance points along the tunnels.

54
 Figure 5.2: Map of the Edgar mine in Idaho Springs, CO.

The first tests are in the straight sections of the Miami and Army tunnels. The
cross sectional shape of the Miami tunnel has a diameter of about 12 ft (3.6 m), while
the Army tunnel has a diameter of about 20 ft (6 m). The SNR versus LOS distance
results are shown in Figure 5.3. From the results, it is obvious that signals are not
attenuated as quickly within the Miami tunnel as in the Army tunnel. This could
be for many reasons, but most likely is due to a stronger waveguide effect within the
Miami tunnel. Since the Miami tunnel has a smaller size in relation to the wavelength

55
of the signal, it has a greater waveguide effect and therefore smaller attenuation.

(a) Miami tunnel.

(b) Army tunnel.

Figure 5.3: Signal strength vs. distance.

5.1.3 Edgar Mine Signal Strength vs. Distance (Non-LOS)

The next test considered a 90◦ turn at 750 ft (228 m) within the Miami tunnel,
as shown in Figure 5.4. Figure 5.5 shows the SNR versus Non-LOS distance as we
moved into the turn at varying distances. From the results, it is easy to see that signal
strength is attenuated very quickly when a turn around a corner is taken within a
mine. From comparing the signal attenuation slope for both the LOS test and the
non-LOS tests, the non-LOS signal drops at a rate of approximately twenty times
quicker than the LOS signal.

56
 Figure 5.4: Miami non LOS branch.

Figure 5.5: Signal strength vs. distance.

5.1.4 Network Analysis/Evaluation

The experiments confirm our assumptions and match the results from other inde-
pendent researchers about transmitting signals in subterranean environments [5] [16].
The corresponding data shows low losses for straight tunnels because of waveguiding
effects. This matches previous research that has shown the path loss exponent for

57
subterranean environments to have a lower value than that of free space [5]. Our
other data shows extremely high attenuation around corners, up to twenty times
higher than line of sight placement. This is due to the high bending loss from non
specular reflection off jagged walls, matching independent research [5].
These results ultimately show that LOS placement of equipment is typically the
optimum solution, but it is still possible to gather some usable signal strength around
corners (which would be impossible with shorter wavelength communication systems
like light).

5.2 AMR Signal Strength Navigation

Two types of tests are used to display the ability to navigate by radio signal
strength. One test uses humans and the other uses autonomous robots. Both types
of experiments are controlled by a computer that analyzes the radio signal strength to
adjacent communication nodes and determines the direction to go for either a human
or autonomous robot (also known as the AMR).

5.2.1 Human only Experiments

Before the AMR was completely ready, we performed two experiments simulating
how an autonomous robot would navigate and position itself for optimal relaying of
data. This was done by using a human with a Rajant radio node and a laptop which
observed the radio signal strength (RSS) between the nodes in front of and behind
the human AMR. An algorithm on the computer made computations and displayed
directions to the human; directing him/her to ”Move Forward,” ”Move Backwards,”
or ”Stop.” In the first experiment there was one leader node far away from the base
station. The AMR (a human directed by the algorithm) moves to position itself at
an equal RSS away from both the leader and the base station, acting as a relay for
data. Figure 5.6 shows that the system did command the AMR (human) to move

58
to the correct location so that the RSS between the AMR and the base is essentially
the same as between the AMR and the leader. The same type of human-in-the-loop
experiment was performed using two AMRs (humans) and the results are shown in
Figure 5.7. The two human AMRs equalize the signal strength between their two
adjacent nodes. Unfortunately, the battery died on one laptop leaving AMR three
unfinished with the experiment and not at equal radio signal strength. However,
up to that point it can be seen that the radio signal strength (SNR) from both the
leader and follower become equal as the AMRs navigate only by the signal strength
measurements they receive.

Figure 5.6: Computer commanded RSS following with a human in the loop.

Figure 5.7: Computer commanded RSS following with two humans in the loop.

59
5.2.2 AMR RSS Positioning Without Wall Following

Another experiment used a single semi-autonomous robotic AMR. Here, semi-

autonomous means that a human performed steering, as autonomous wall-following
was not functional at the time of the test. As in the previous human based experi-
ments described above, directional motion of the AMR was commanded by the RSS
control algorithm and this command was executed autonomously. The only role of
the human was to steer during AMR movements. The AMR navigated from the base
station to the optimal position, guided by only the signal strengths to the leader node
and base station (follower) node. The AMR would gather radio signal data for 30
seconds and then move to an estimated position. It would then repeat the gathering
of data for 30 seconds and reposition again if necessary. The AMR repeated the gath-
ering of data and moving five times during the experiment, until it ultimately reached
its goal of equal signal strength between the leader and base station (follower). Fig-
ure 5.8 shows the resulting signal strength plots and distance versus time. Figure 5.9
shows the corresponding locations within the mine. Clearly, the algorithm was effec-
tive in achieving a balanced RSS between the AMR and the base and between the
AMR and the leader.

Figure 5.8: Semi autonomous RSS positioning plot.

60
 Figure 5.9: Corresponding semi autonomous RSS positioning map.

5.2.3 Completely Autonomous AMR RSS Positioning

On April 2, 2010 we completed a successful test using the autonomous AMR with
wall following implemented. A leader node was placed at a far position within the
mine to simulate the path of a leading teleoperated vehicle venturing too far away
from radio communications. An AMR was given the task to relocate and relay in-
formation from the leader node back to the base station. In the experiment, the
AMR successfully relocated itself to find the optimal location for relaying informa-
tion. Secondly, in the same experiment, after the AMR had successfully positioned
itself at the optimal location, the leader then moved even further away. This caused
the signals strengths to become imbalanced and the AMR automatically took action
and repositioned itself again, this time in the new optimal location for relaying infor-
mation. The signal strength data for this successful test is seen in Figure 5.10 and
the corresponding map is shown in Figure 5.11.
Figure 5.10 shows the leader and base-station SNRs that are relative to the AMR.
These two SNRs directly correspond to the received signal strengths from the leader
and base station to the AMR. As can be seen at the beginning of Figure 5.10 the SNR
to the leader is low, while the SNR to the base-station is high. This is because the
AMR starts its journey near the base-station and moves toward the leader. As time

61
 Figure 5.10: Autonomous RSS positioning plot.

Figure 5.11: Corresponding autonomous RSS positioning map.

progresses, it is shown that the SNRs slowly change to meet in the middle where they
are roughly equal. It is at this point where the leader moves further away causing
the SNRs to be unbalanced again. The AMR then relocates to compensate and thus
the SNRs are back to nearly the same. Figure 5.11 shows the locations of the leader
and the base-station, as well as the path of the AMR as it moves and stops within
the Army tunnel of the Edgar mine.

5.2.4 AMR RSS Navigation Summary

Several preliminary tests showed the ability of AMR subsystem to autonomously

position itself based on radio signal strength to adjacent wireless nodes. By imple-
menting a simple method of navigating based on the signal strength to neighboring
nodes along with autonomous wall following and smart sensing, the AMR is capable

62
of providing uninterrupted radio communications between a teleoperated vehicle in a
subterranean mine with its driver at the base station.

5.3 Bobcat Experiments

The Bobcat front-end loader was independently tested in three ways: several tests
for operability and safety, a control time delay test, and a subterranean control test
within the Edgar mine.

5.3.1 Teleoperated Control

In order to safely test the full functionality of the modified Bobcat remote control
system, the Bobcat was placed on jack stands, as seen in Figure 5.12, and had an
emergency off switch manned at all times. The remote control system was tested
in several stages. First was control over a wired Ethernet cable. Secondly, was
control using the line of sight but wireless controller. Lastly, the system was tested
with the wireless Rajant Breadcrumb network, with several stages of hopping and
camera based operation. Teleoperated control is seen through webcams, as seen in
Figure 5.13.
The Bobcat remote control system was tested for control of individual components,
responsiveness of control, and the fail safe conditions to prevent accidents. The
following scenarios were tested to ensure the operation of fail safe programming and
safety of operation:

1.) Ethernet loss of connection.

2.) Moving during a Ethernet loss of connection.
3.) Moving during a loss of power.
4.) Mainboard to microprocessor loss of communication.

63
 Figure 5.12: Bobcat.

During each safety test the Bobcat sequentially passed through each safety mode,
where the depth of the safety mode depends on the severity of the connection distur-
bance.

1st stage: Stops movement of the tires and bucket.

2nd stage: Enables the parking brake and locks the bucket.
3rd stage: Shuts down the Bobcat.

These stages occur within microseconds and provide safety without compromising
continuous operation.

5.3.2 Time Delay

Quantifying the performance of the teleoperated Bobcat with the Rajant wireless
network, can be done by measuring the time it takes a change in data to move from
the controls to the vehicle. Data that measured how long a signal took to propagate

64
 (a) Camera One. (b) Camera Two.

Figure 5.13: Teleoperation testing.

from the controller to the vehicle was collected. This time delay data was processed
into a histogram to visualize trends and can be seen in Figure 5.14.
Histogram estimate of time delay(ms)
40

35

30

25
Count

20

15

10

0
0 100 200 300 400 500 600 700
Time (ms)

Figure 5.14: Teleoperated network delay.

Two trends stand out and are centered at around 120ms and 220ms. Regardless
of which trend is analyzed, the majority of time delay is less than 250ms and there
are outliers to be expected from a wireless system that might see fades of lost data.

65
Additional delay from more wireless hops was analyzed and showed no appreciable
delay. Zero delay is the ultimate goal, but this is a reasonable time delay to deal with
for our purposes.

5.3.3 Bobcat Subterranean Navigation

The last test, before a complete system mock disaster scenario test, was to see
how the Bobcat and Rajant network would perform in the Army section of the Edgar
mine. The Bobcat was outfitted with extra lights, so that the Ethernet-based camera
could see, and was sent into the mine, as depicted in Figure 5.15.

Figure 5.15: Bobcat underground.

The base station was set up to display the camera feed and to log data for the
experiment. The user then actuates the Bobcat controller from the base station,
while viewing the camera feed from a laptop display, as seen in Figure 5.16.
From the user’s perspective, one camera provides the viewpoint that an operator
might see from inside the cab of the Bobcat. Video quality was sacrificed to provide
the base station user a higher frame rate and better responsiveness. A sample video
feedback single frame is shown in Figure 5.17.

66
 Figure 5.16: Base station control.

Figure 5.17: Bobcat teleop. field of view.

Like the previous human-only RSS navigation experiments, a human acted as the
role of an AMR. In doing so they moved in steps to maintain the best connection for
the Bobcat front-end loader and equal value signal strength to both the base station
and the Bobcat. As can be seen in Figure 5.18(a), whenever the AMR moved the
signal strengths merged to be nearly equal. However, when the Bobcat proceeds
further into the mine, the signal strength from the AMR to the Bobcat decreases.

67
The relative locations for the Bobcat, the human AMR, and the Base Station can all
be seen in Figure 5.18(b)

(a) Radio Signal strength.

(b) Map Overview.

Figure 5.18: Bobcat test: AMR RSS data.

68
5.3.4 Bobcat Performance Analysis

The Bobcat performed exceptionally well within the mine and was able to traverse
to the signal’s strength limit for carrying a video stream from three Rajant nodes,
which was about 500 ft into the mine with several turns. This depth of penetration
would not have been possible without the AMR acting as a relay and could have been
even further with more AMRs.

5.4 Complete System Test

As a final proof-of-concept, we took all the elements from this project and previous
tests to perform a complete system test at the Edgar experimental mine on November
9, 2010. This test utilized the teleoperated Bobcat front-end loader, the completely
autonomous mobile radio vehicle, and the Rajant Wi-Fi mesh network. The two
vehicles create a search and rescue caravan that can be seen in Figure 5.19.

Figure 5.19: Search and rescue caravan.

The base station allowed a user to teleoperate the Bobcat front-end loader and si-
multaneously view any problems with the AMR, as shown in Figure 5.20.

69
 (a) The user controls the Bobcat.

(b) Video feedback from both vehicles.

Figure 5.20: Base station.

The test outline was to penetrate the teleoperated front-end loader in the mine looking
for danger zones and possible victims, while the AMR moves when necessary to
maintain equal signal strength to both the Bobcat front-end loader and the base
station. The first test can be seen in Figure 5.21, where the Bobcat front-end loader

70
moved three times and the AMR moved multiple times to equalize the signal strength.
The RSS from the AMR can be seen for the base station and the Bobcat. As the
AMR moves, the signal strengths trend towards each other. The AMR autonomously
moved a distance of about 56 meters, while the Bobcat traveled about 106 meters
under the teleoperated control of the user at the base station.

(a) RSS data.

(b) Map.

Figure 5.21: Test one.

71
The second test, shown in Figure 5.22, was a repeat of the first test, again the Bobcat
moved forward on its own mission while the AMR tried to maintain equal signal
strength. The test performed well except for an error in the wall following routine of
the AMR. At about 12:18 PM the AMR came too close to the wall and the emergency
stop was hit. The vehicle was manually repositioned away from the wall and the test
was resumed.

(a) RSS data.

(b) Map.

Figure 5.22: Test two.

5.5 Complete System Analysis

From both of the complete systems tests, a proof-of-concept can easily be seen.
The tests were both successful despite a minor wall following error in the second test.

72
The point of the AMR was to create a seamless wireless network for the teleoperated
front-end loader and it performed its task well. The Bobcat traveled so far into the
mine that a single link would not have been sufficient for control. Thus, the AMR
was a necessary part of the system.

5.6 Conclusions

In this chapter the radio wave propagation characteristics, described in Chapter

2, are verified with several tests using the subterranean tunnels at the Edgar Ex-
perimental Mine in Idaho Springs, Colorado. Secondly, several tests were performed
on individual elements of the complete search and rescue caravan. The Bobcat was
tested first to ensure hardware and software operability along with safety procedures.
The Rajant network was tested to verify the ability to capture signal strength mea-
surements and the feasibility of navigation by those signals. The AMR was tested for
autonomous behavior in navigating obstacles and for following signal strength mea-
surements. Lastly all the elements came together for a complete system test where
the Bobcat front-end loader was teleoperated into the mine with an AMR following
it using only its sensors. The Bobcat was seamlessly controlled far into the mine, at
a point where a single direct wireless signal would not have been sufficient. Thus the
experiment worked with the autonomous vehicle acting as a relay to maintain the
wireless connection to the teleoperated Bobcat.

73
 CHAPTER 6
CONCLUSIONS

One goal of this thesis was to show that wireless teleoperated control is possible
within an underground mine. However, in the absence of a fixed infrastructure it is
only made possible by utilizing relaying equipment with the ability to reposition. The
experiments from Chapter 5 have shown that a search and rescue robot could enter
a subterranean mine with its own independent communications equipment and still
communicate to the outside via several wireless relays atop autonomous vehicles. In
our experiments we successfully teleoperated a Bobcat front-end loader at a maximum
of about 350 ft (106 m) in a mine section containing a bend while utilizing a wireless
relay atop an autonomous vehicle. The autonomous vehicle positioned itself at the
optimal location for relaying signals to allow the best quality video feedback and
wireless range.

6.1 Recommendations for Future Work

There are a few things that would be beneficial for search and rescue robots in
subterranean mines. Ethernet-based air quality monitors would provide life-saving
information to rescue workers. A UHF radio-to-Ethernet interface for communicating
to existing leaky feeder communication lines would allow rescuers to possibly reestab-
lish communications to isolated sections of the mine. Lastly, the teleoperated vehicle
would benefit from the addition of better cameras and external sensors to help the
user with controlling the vehicle or by adding semi-autonomy.

6.2 Implications of Research

The implications of this research are two-fold. First, creation of an Ethernet

controlled teleoperated vehicle has almost limitless potential with existing global net-

75
works. Since Ethernet and Wi-Fi are interconnectable with the internet, any vehicle
with Ethernet ability could be controlled from almost any location on the planet.
Secondly, the mobile mesh network allows the teleoperated vehicle to greatly expand
its working environment to penetrate otherwise unreachable areas. The mesh network
might simply be used to extend the range of a teleoperated vehicle or in this case
allow a vehicle to venture far into a subterranean mine.

76
 REFERENCES CITED

[1] “Sago mine information single source page”, MSHA, Dec. 7, 2007. [Online].
Available: http://www.msha.gov/sagomine/sagomine.asp [Accessed: Jan. 24,
2011].

[2] “Loader radio remote control system”, Bobcat Company, Jan. 25, 2008.
[Online]. Available: http://www.bobcat.com/loaders/remote control [Accessed:
Jan. 24, 2011].

[3] T. Rappaport, Wireless Communications: Principles and Practice. Upper

Saddle River, NJ: Prentice Hall PTR, 2002, ch. 4, pp. 113–137.

[4] A. Molisch, Wireless Communications. West Sussex, England: Wiley-IEEE

Press, 2005, ch. 2-4, pp. 25–64.

[5] J. Peeke, “Wireless link control for cooperative robotic exploration,” M.S.
thesis, Dept. Eng., Colorado School of Mines, Golden, CO, 2006, T-6158.

[6] S. Hirose and E. Fukushima, “Snakes and strings: New robotic components for
rescue operations,” The International Journal of Robotics Research, vol. 23, no.
4-5, p. 341, April, 2004.

[7] R. Murphy, J. Kravitz, S. Stover, and R. Shoureshi, “Mobile robots in mine

rescue and recovery,” Robotics & Automation Magazine, IEEE, vol. 16, no. 2,
pp. 91–103, June, 2009.

[8] M. Akin and F. Crabbe, “Mobile vehicle teleoperated over wireless IP,” U.S.
Naval Academy Comput. Sci. Dept., Annapolis, MD, Tech. Rep. ADA469238,
June, 2007.

[9] A. Ferworn, N. Tran, J. Tran, G. Zarnett, and F. Sharifi, “WiFi repeater

deployment for improved communication in confined-space urban disaster
search,” in System of Systems Engineering, 2007. SoSE’07. IEEE International
Conference on. San Antonio, TX: IEEE, 2007, pp. 1–5.

[10] K. Shima, Y. Uo, and S. Fujita, “Auto configuration and management

mechanism for the robotics self extensible WiFi network,” in SICE Annual
Conference, 2008. Tokyo, Japan: IEEE, 2008, pp. 1648–1652.

77
[11] “Rajant BreadCrumb ME2 data sheet”, Rajant Corporation. [Online].
Available:
http://www.rajant.com/pdf/Rajant BreadCrumb ME2 Data Sheet.pdf
[Accessed: Jan. 24, 2011].

[12] E. Larson, “Unpublished,” M.S. thesis, Dept. Eng., Colorado School of Mines,
Golden, CO, 2011.

[13] J. Hulbert, “Unpublished,” M.S. thesis, Dept. Eng., Colorado School of Mines,
Golden, CO, 2011.

[14] “Sparkfun home page”, Sparkfun. [Online]. Available:

http://www.sparkfun.com [Accessed: Jan. 24, 2011].

[15] “Arduino Ethernet Shield MEGA hack”, NKC Electronics Tutorials, April
14th, 2009. [Online]. Available:
http://mcukits.com/2009/04/06/arduino-ethernet-shield-mega-hack/
[Accessed: Jan. 24, 2011].

[16] M. Weiss, J. Peak, and T. Schwengler, “A statistical radio range model for a
robot MANET in a subterranean mine,” IEEE Transactions on Vehicular
Technology, vol. 57, no. 5, pp. 2658–2666, Sept., 2008.

78
 APPENDIX A - A

The appendix provides references for reconstructing the project from hardware to
software.

A.1 Circuit Diagrams

The circuit diagrams here are for reference purposes, the files needed to recreate
these circuit boards are on the included CD.

A.1.1 RX

5 4 3 2 1

J14

1
2
3.3V

Power Switch

5V U5 U6 U7
3VReg 5VReg 9VReg

J2 J16

GND

GND
OUT

OUT

Out
J15

Adj
D 1 D

IN

IN
1

In
2 2 1
3 1 2

1
2
3

1
2
3

1
2
3
3
4 4 2 3
5 5 3 4
6 6 4
7 7
C1 Power sup (12V)
Right Switches
J4 I2C DAC I2C, IC, OC R45 C
1 R
1 R1 J13
2 2 U1 R
J6
Right Paddle 1 VoutA A3 16 1
1 1 2 VoutB A2 15 R46 2
2 2 3 VrefH A1 14 3
4 13 POT 4
Ignition & Estop VDD AO
J5 5 VrefL IOVdd 12
6 11 Q1
GND SDA 2N6659 C2 Ard.. & MainB (Power)
1 1 7 VoutC SCL 10
2 8 9 C
2 VoutD LDAC
J1
Left Paddle DAC6573IPW (DAC)
1 1
2 2 J7
3 3
4 4 1 1
5 5 2 2
6 6 3 3
7 7 4 4

Left Switches Joysticks

C C

Level Conversion
U2
11 B8 GND 10
12 B7 A8 9
13 B6 A7 8 J11
14 B5 A6 7
15 B4 A5 6 1 NC
16 B3 A4 5 2 RP
17 4 R6 3
B2 A3 R2 R LP
18 B1 A2 3 4 Horn
19 2 R3 R 5
OE A1 R4 R float
20 VCC NC 1 6 AD22
R5 R 7
R AD24
Level conv Misc. Switches

R7
U3
R8 R
11 10 R R9
B8 GND R10 R
12 B7 A8 9 J10
13 8 R
B6 A7
14 B5 A6 7 1 AD26
15 B4 A5 6 2 AD28
16 B3 A4 5 3 AD23
17 B2 A3 4 4 AD25
18 3 R11 5
B1 A2 R12 R AD27
19 OE A1 2 6 AD29
20 1 R13 R 7
VCC NC R14 R AD30
R Right Switches
Level Conv
B B
R19
U4
R18 R
11 10 R17 R
B8 GND R16 R J9
12 B7 A8 9
13 8 R 1
B6 A7 AD32
14 B5 A6 7 2 AD34
15 B4 A5 6 3 AD36
16 B3 A4 5 4 AD31
17 B2 A3 4 5 AD33
18 3 R20 6
B1 A2 R R15 AD35
19 OE A1 2 7 AD37
20 1 R22 R
VCC NC R23 R Left Switches
R
Level Conv

A A

R44 R43 R42 R41 R40 R39 R38 R37 R36 R35 R34 R33 R32 R31 R29 R28 R27 R26 R25 R24
R R R R R R R R R R R R R R R R R R R R

D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9 D8 D6 D5 D4 D3 D2 D1
LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED Title
Microcontroller Interface Board

Size Document Number Rev

Custom1 1

Date: Saturday, August 14, 2010 Sheet 1 of 1

5 4 3 2 1

Figure A.1: RX Interface Board

79
 5 4 3 2 1

5V Linear Regulators
U1 U2 U3 U4
7805 7805 7805 7805 J11
D J8 D
1
Power Input 2

In
GND
Out
In
GND
Out
In
GND
Out
In
GND
Out
3
4

1
2
3
1
2
3
1
2
3
1
2
3
5

1
2
3
4
5
6
6
7
8
D2 9
LED 10
C C

D1 5V header
Protection DIODE C4
C R3
C3 R
C

2
1
B B

4
3
2
1
2
1
J5
J10
Power Switch J9 12V electronics
Battery Backup Input

1
2
3
4
5
Title
Bobcat RX Power Distribution
A A
J7
Rajant Size Document Number Rev
Custom<Doc> 2

Date: Saturday, August 14, 2010 Sheet 1 of 1

5 4 3 2 1

80
Figure A.2: RX Power Distribution Board
A.1.2 TX

5 4 3 2 1

J5
5V Power (Paddles)
U2
U1 3.3V Regulator
5V Regulator

1
2
3
4
D D

1
2
3
1
2
3
J3

GND Line Connector

2
R1
R
J6
Power in (9.6V)
1
2
3
D1 4

1
2
3
4
5
6
C
LED C
CON4

J4
9.6V Power Out

3.3V Side (Ref Pulse, Data out, Horn, Float Com)

1 1 7
2 2 8
B 3 3 9 B
4 4 10
5 11 5V Side (Ref Pulse, Data out, Horn, Float Com)
J8 6 12
1
2
3
Level Converter 4

J9

A A
Title
TX Interface PCB

Size Document Number Rev

Custom<Doc> 2

Date: Saturday, August 14, 2010 Sheet 1 of 1

5 4 3 2 1

Figure A.3: TX Interface Board

5 4 3 2 1

J3
CON3
1
2
3

D D

C1 C2
10uF 10 uF I2C I/O U4Expansion Chip
R19
Shift Register Chip R18 2.2k I2C I/O U9Expansion Chip
1 24 2.2k
J4 Inverter
U3 Chip U2
2
INT
A1
VCC
SDA 23 Shift Register Chip Shift U8Register Chip 1 INT VCC 24
10 1 14 9 8 3 22 2 23
9 2
1A
1Y
Vcc
6A 13 10
QH'
SRCLR'
GND
QH 7 4
A2
P00
SCL
A0 21 U1 9 QH' GND 8 3
A1
A2
SDA
SCL 22 Shift Register Chip
8 3 2A 6Y 12 11 SRCLK QG 6 5 P01 P17 20 10 SRCLR' QH 7 4 P00 A0 21 U7
7 4 2Y 5A 11 12 RCLK QF 5 6 P02 P16 19 1 QB VCC 16 11 SRCLK QG 6 5 P01 P17 20
6 5 3A 5Y 10 13 OE' QE 4 7 P03 P15 18 2 QC QA 15 12 RCLK QF 5 6 P02 P16 19 1 QB VCC 16
5 R17 6 9 14 3 8 17 3 14 13 4 7 18 2 15
220 k 3Y 4A SER QD P04 P14 QD SER OE' QE P03 P15 QC QA
C
4 7 GND 4Y 8 15 QA QC 2 9 P05 P13 16 4 QE OE' 13 14 SER QD 3 8 P04 P14 17 3 QD SER 14 C
3 16 VCC QB 1 10 P06 P12 15 5 QF RCLK 12 15 QA QC 2 9 P05 P13 16 4 QE OE' 13
2 MC74HC04 11 P07 P11 14 6 QG SRCLK 11 16 VCC QB 1 10 P06 P12 15 5 QF RCLK 12
1 sn74hc595dwr 12 GND P10 13 7 QH SRCLR' 10 11 P07 P11 14 6 QG SRCLK 11
8 GND QH' 9 sn74hc595dwr 12 GND P10 13 7 QH SRCLR' 10
PCF8575CDWR 8 GND QH' 9
Clock,Ref pulse,VCC,GND,PCM,SDA,SCL, latch sn74hc595dwr PCF8575CDWR
sn74hc595dwr
U5
1 A1 Vcc 14
2 B1 B4 13
3 Y1 A4 12
1: N.A. 4 A2 Y4 11
2: N.A. 5 B2 B3 10
B 3: Shift Reg. Latch 6 9 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 B
Y2 A3 D25 D26 D27 D28 D29 D30 D31 D32 D17 D18 D19 D20 D21 D22 D23 D24
4: I2C SCL 7 GND Y3 8 LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED
5: I2C SDA LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED LED
6: Pulse Code Modulation (PCM)-Joystick Data out
7: GND
74ls08 LEDs
8: Vcc LEDs
9: Joystick Ref Pulse R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16
U6 R R R R R R R R R R R R R R R R R20 R21 R22 R23 R24 R25 R26 R27 R28 R29 R30 R31 R32 R33 R34 R35
10: Clock
1 14 R R R R R R R R R R R R R R R R
CLR1 VCC
2 D1 CLR 2 13
3 CLK 1 D2 12
4 11
5
PR 1 CLK 2
10 LEDs
6
Q1
Q1'
PR 2
Q2 9 LEDs
A
7 GND Q2' 8 A
Title
74hc74 <Title>

Size Document Number Rev

Custom<Doc> 3

Date: Saturday, August 14, 2010 Sheet 1 of 1

5 4 3 2 1

Figure A.4: Joystick I2C Interface Board

81
A.2 Code

The first two sections of code is for the Bobcat teleoperation system and the last
section of code is the AMR server. The Bobcat teleoperation code was created for the
Arduino development environment, version 10.0. The AMR server code was created
with the Jython programming language.

A.2.1 Arduino Ethernet Shield library modification

The following code needs to be modified to make the Arduino Ethernet shield
compatible with the Arduino Mega.
Locate the file ”spi.h” in the ”hardware/libraries/Ethernet/utility directory”, un-
der the Arduino installation [15].
Find the following lines:

Listing A.1: Original spi.h code

#define SPI0 SS BIT BIT2

...
#define SPI0 SCLK BIT BIT5
...
#define SPI0 MOSI BIT BIT3
...
#define SPI0 MISO BIT BIT4
...
#define IINCHIP CS BIT BIT2
...
PORTB |= SPI0 SS BIT ; PORTB &= ˜ ( SPI0 SCLK BIT | SPI0 MOSI BIT ) ; \

and replace them with this code:

Listing A.2: Modified spi.h code

#define SPI0 SS BIT BIT4

...
#define SPI0 SCLK BIT BIT1
...
#define SPI0 MOSI BIT BIT2
...

82
#define SPI0 MISO BIT BIT3
...
#define IINCHIP CS BIT BIT4
...
PORTB |= SPI0 SS BIT | BIT0 ; PORTB &= ˜ ( SPI0 SCLK BIT |
SPI0 MOSI BIT ) ; \

A.2.2 RX Arduino

Listing A.3: Host/Receiver Code

#include <E t h e r n e t . h> // E t h e r n e t L i b r a r i e s

#include <Wire . h> // I2C l i b r a r i e s
// S e r i a l p o r t com6
// network c o n f i g u r a t i o n . gateway and su b n et a r e o p t i o n a l .
byte mac [ ] = { 0xDE, 0xAD, 0xBE , 0xEF , 0xFE , 0xED } ;
byte i p [ ] = { 1 6 9 , 2 5 4 , 0 , 72 } ;
byte gateway [ ] = { 1 6 9 , 2 5 4 , 0 , 1 } ;
byte s u b n e t [ ] = { 2 5 5 , 2 5 5 , 0 , 0 } ;

S e r v e r s e r v e r = S e r v e r ( 2 3 ) ; // S e r v e r p o r t number

int numbytes = 9 ;
byte Data [ 9 ] ;
int j = 0 ;
int k = 0 ;
byte OCData = 0 ;
byte TimerRegA = 0 ;
byte Mask = B10000000 ;

char c1 ;
char c2 ;
int L o s t C o n n e c t i o n F l a g = 0 ;
int t i m e o u t i n d e x = 0 ;
int l a s t = 0 ;

int L e f t P a d d l e = 5 1 2 ; // 10 b i t s s o o n l y 0 through 1023

int RightPaddle = 5 1 2 ; // 10 b i t s s o o n l y 0 through 1023
byte f i r s t ; // used f o r I2C communication
byte s e c o n d ; // used f o r I2C communication

byte JoyData [ 4 ] ; // J o y s t i c k data

void s e t u p ( ) {
S e r i a l . begin (9600) ;

83
 S e r i a l 1 . begin (9600) ;
S e r i a l . p r i n t l n ( ” I n i t i a l i z i n g the ethernet device . . . ” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” I n i t i a l i z i n g the ethernet device ” ) ;
Wire . b e g i n ( ) ; // s t a r t i 2 c bus f o r DAC
delay (5000) ;
E t h e r n e t . b e g i n ( mac , ip , gateway , s u b n et ) ; // I n i t i a l i z e s t h e
e t h e r n e t l i b r a r y and network s e t t i n g s .
delay (1000) ;
server . begin () ; // T e l l s t h e s e r v e r t o b e g i n l i s t e n i n g f o r
incoming c o n n e c t i o n s .
S e r i a l . p r i n t l n ( ” Looking f o r c l i e n t s ” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Looking f o r clients ”) ;
Data [ 9 ] = ’ /0 ’ ; // p r e v e n t EEPROM o v e r r u n

DDRL = B00001000 ; // S e t s t h e Data d i r e c t i o n r e g i s t e r o f p o r t L

( p i n 46 ( PL3 ) i s output , p i n 48 ( Pl1 ) i s an i n p u t )
TCCR5A = B00000000 ; // ( t i m e r 5 c o n t r o l r e g i s t e r A) d i s a b l e
output compare i n i t i a l l y , e n a b l e ” normal ” waveform
g e n e r a t i o n mode
TCCR5B = B00000001 ; // ( t i m e r 5 c o n t r o l r e g i s t e r B) Enable i n p u t
c a p t u r e on f a l l i n g edge and f i l t e r , e n a b l e ” normal ”
waveform g e n e r a t i o n mode , s e t t h e p r e s c a l e r t o 1 ;
TIMSK5 = B00100010 ; // Enable IC ISR , d i s a b l e OC ISR

SetupOutputs ( ) ; // S e t Data D i r e c t i o n r e g i s t e r s
I n i t i a l i z e O u t p u t s ( ) ; // S e t d e f a u l t p o s i t i o n s f o r o u t p u t s
s e i ( ) ; // e n a b l e i n t e r u p t s
}

void l o o p ( ) {
Client c l i e n t = server . available () ;
if ( client ) {
S e r i a l . p r i n t l n ( ” C l i e n t Connected ” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” C l i e n t Connected ” ) ;
LostConnectionFlag = false ;
last = 0;
while ( c l i e n t && ! L o s t C o n n e c t i o n F l a g ) {
c1 = c l i e n t . r e a d ( ) ;
i f ( c1 == −2 && l a s t == −2){ // s t a r t c o n d i t i o n
f o r ( int i =0; i < numbytes ; i ++){ // r e a d t h e next
nine bytes
Data [ i ] = c l i e n t . r e a d ( ) ;
}
c1 = c l i e n t . r e a d ( ) ;

84
 c2 = c l i e n t . r e a d ( ) ;
i f ( c1 == −3 && c2 == −3){ // s t o p c o n d i t i o n
passed
UpdataData ( ) ;
i f ( t i m e o u t i n d e x >0){
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” R e c e i v i n g Data” ) ;
}
timeoutindex = 0;
S e r i a l . p r i n t l n ( ”P” ) ;
// c l i e n t . p r i n t ( 2 5 4 ,BYTE) ; // r e c e i v e
acknowledge
} e l s e { // s t o p c o n d i t i o n f a i l e d ( a b o r t )
client . flush () ;
// S e r i a l . p r i n t l n ( ”F” ) ;
}
} e l s e i f ( c1 == −1 && l a s t == −1){
t i m e o u t i n d e x ++;
S e r i a l . p r i n t l n ( ”FFF” ) ;
client . flush () ;
i f ( t i m e o u t i n d e x >3){ //maybe l o s t c o n n e c t i o n
SafetyPosition () ;
S e r i a l . p r i n t l n ( ” i n s a f e mode 1” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” In s a f e mode 1” ) ;
}
i f ( t i m e o u t i n d e x >8){ //maybe l o s t c o n n e c t i o n
d i g i t a l W r i t e ( 3 1 , LOW) ; // Operate / Loader
Switch ( o p e r a t e ) (DSub−12)
d i g i t a l W r i t e ( 3 3 , HIGH) ; // Operate / Loader
Switch ( d i s a b l e ) ( DSub−30)

d i g i t a l W r i t e ( 2 6 , HIGH) ; // Park Brake High (On

) ( DSub−31)
d i g i t a l W r i t e ( 2 8 , LOW) ; // Park Brake Low( O f f )
(DSub−13)
S e r i a l . p r i n t l n ( ” i n s a f e mode 2” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” In s a f e mode 2” ) ;
}
i f ( t i m e o u t i n d e x >20){ // r e s e t l o s t c o n n e c t i o n
S e r i a l . p r i n t l n ( ” i n s a f e mode 3” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” In s a f e mode 3” ) ;
}
i f ( t i m e o u t i n d e x >30){ // D e f i n i t e l y l o s t
connection

85
 EStop ( ) ;
client . flush () ;
c l i e n t . stop () ;
L o s t C o n n e c t i o n F l a g = true ;
}
delay (100) ;
}
l a s t = c1 ;
}
S e r i a l . p r i n t l n ( ” Connection f a i l e d ” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Connection Failed ”) ;
client . flush () ;
c l i e n t . stop () ;
delay (1000) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Looking f o r clients ”) ;
}
}

void UpdataData ( ) {
PORTA = Data [ 0 ] ; // L e f t s i d e s w i t c h s e t and E−Stop ( 2 2 t o 2 9 )
PORTC = Data [ 1 ] ; // Right s i d e s w i t c h s e t and i g n i t i o n ( 3 0 t o
37)
PORTG = ( Data [2] > >6) ; // Horn and f l o a t (PG1−b i t 7 and PG0−b i t
6)

L e f t P a d d l e = word ( Data [ 3 ] , ( Data [ 2 ] & B00110000 )<<2)>>6;

RightPaddle = word ( Data [ 4 ] , ( Data [ 2 ] & B00001100 )<<4)>>6;

JoyData [ 1 ] = Data [ 5 ] ; // f i r s t byte

// S e r i a l . p r i n t l n ( JoyData [ 0 ] , BIN ) ;
JoyData [ 0 ] = Data [ 6 ] ; // s ec o n d byte
JoyData [ 3 ] = Data [ 7 ] ; // t h i r d byte
JoyData [ 2 ] = Data [ 8 ] ; // f o u r t h byte
SendI2C ( ) ;
}

void S a f e t y P o s i t i o n ( ) {
JoyData [ 0 ] = 0 ;
JoyData [ 1 ] = 0 ;
JoyData [ 2 ] = 0 ;
JoyData [ 3 ] = 0 ;
}
void EStop ( ) {
d i g i t a l W r i t e ( 2 9 , LOW) ; //E−Stop e n a b l e

86
 d i g i t a l W r i t e ( 3 1 , LOW) ; // Operate / Loader Switch ( o p e r a t e ) ( DSub
−12)
d i g i t a l W r i t e ( 3 3 , HIGH) ; // Operate / Loader Switch ( d i s a b l e ) ( DSub
−30)

d i g i t a l W r i t e ( 2 6 , HIGH) ; // Park Brake High (On) (DSub−31)

d i g i t a l W r i t e ( 2 8 , LOW) ; // Park Brake Low( O f f ) (DSub−13)

InitializeOutputs () ;
S e r i a l . p r i n t l n ( ” i n E−s t o p mode” ) ;
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” In E−s t o p mode” ) ;
}

void SetupOutputs ( ) {
// Port A 22 through 29
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// L e f t s i d e s w i t c h s e t
pinMode ( 2 2 , OUTPUT) ; // L e f t S k i Switch High
(DSub−41)
pinMode ( 2 3 , OUTPUT) ; // A u x i l i a r y H y d r a u l i c A c t i v a t i o n
s w i t c h High ( DSub−44)
pinMode ( 2 4 , OUTPUT) ; // L e f t S k i Switch Low
(DSub−42)
pinMode ( 2 5 , OUTPUT) ; // A u x i l i a r y H y d r a u l i c A c t i v a t i o n
s w i t c h Low ( DSub−43) NOTE: not i n v e r s e s , but both cannot
be e n a b l e d a t t h e same time . A t h r e e s t a t e s w i t c h
pinMode ( 2 6 , OUTPUT) ; // Park Brake High (On)
(DSub−31)
pinMode ( 2 7 , OUTPUT) ; // Detent Switch
(DSub−45)
pinMode ( 2 8 , OUTPUT) ; // Park Brake Low( O f f )
(DSub−13)

// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// I g n i t i o n and E−Stop
pinMode ( 2 9 , OUTPUT) ; // E−Stop d i s a b l e d v i a h i g h s i g n a l
( DSub−35) ( r e q u i r e s a low p u l s e t o r e s e t i f
something o c c u r s )
pinMode ( 3 0 , OUTPUT) ; // S t a r t I g n i t i o n Hold f o r a t l e a s t
5 s e c o n d s ( DSub−48)

// Port C 30 through 37 ( backwards )

// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// Right s i d e s w i t c h s e t

87
 pinMode ( 3 1 , OUTPUT) ; // Operate / Loader Switch ( o p e r a t e )
( DSub−12)
pinMode ( 3 2 , OUTPUT) ; // Speed management
( DSub−26)
pinMode ( 3 3 , OUTPUT) ; // Operate / Loader Switch ( d i s a b l e )
( DSub−30)
pinMode ( 3 4 , OUTPUT) ; // Speed C o n t r o l h i g h (+)
( DSub−27)
pinMode ( 3 5 , OUTPUT) ; // Right S k i Switch High
(DSub−46)
pinMode ( 3 6 , OUTPUT) ; // Speed C o n t r o l low (−)
(DSub−28) NOTE: not i n v e r s e s ,
but both cannot be e n a b l e d a t t h e same time . A t h r e e s t a t e
switch
pinMode ( 3 7 , OUTPUT) ; // Rigth S k i Switch Low
(DSub−47) NOTE: not i n v e r s e s ,
but both cannot be e n a b l e d a t t h e same time . A t h r e e s t a t e
switch

// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// horn & f l o a t bucket ( Port G)
pinMode ( 4 0 , OUTPUT) ; // Horn Enable
(DSub−29)
pinMode ( 4 1 , OUTPUT) ; // F l o a t bucket Enable
(DSub−25)

// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// Paddles ( 4 5 , 4 7 , 4 9 i n p o r t L)
pinMode ( 4 5 , OUTPUT) ; // No Connection
pinMode ( 4 7 , OUTPUT) ; // Right Paddle Enable
(DSub−15)
pinMode ( 4 9 , OUTPUT) ; // L e f t Paddle Enable
(DSub−14)
}

void I n i t i a l i z e O u t p u t s ( ) {
// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ( 4 5 , 4 7 , 4 9 i n p o r t L)
// Paddles , horn , f l o a t bucket
d i g i t a l W r i t e ( 4 5 , LOW) ; //No Connection
d i g i t a l W r i t e ( 4 7 , LOW) ; // Right Paddle Enable ( DSub−15)
d i g i t a l W r i t e ( 4 9 , LOW) ; // L e f t Paddle Enable (DSub−14)
d i g i t a l W r i t e ( 4 0 , LOW) ; // Horn Enable (DSub−29) ( 4 0 and
41 i n p o r t G)
d i g i t a l W r i t e ( 4 1 , LOW) ; // F l o a t bucket Enable (DSub−25)

// Port A 22 through 29

88
 // ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// L e f t s i d e s w i t c h s e t
d i g i t a l W r i t e ( 2 2 , LOW) ; // L e f t S k i Switch High (DSub−41)
d i g i t a l W r i t e ( 2 4 , LOW) ; // L e f t S k i Switch Low (DSub−42)
NOTE: not i n v e r s e s , but both cannot be e n a b l e d a t
t h e same time . A t h r e e s t a t e s w i t c h
d i g i t a l W r i t e ( 2 6 , HIGH) ; // Park Brake High (On) (DSub−31)
d i g i t a l W r i t e ( 2 8 , LOW) ; // Park Brake Low( O f f ) (DSub−13)
d i g i t a l W r i t e ( 2 3 , LOW) ; // A u x i l i a r y H y d r a u l i c A c t i v a t i o n
s w i t c h High ( DSub−44)
d i g i t a l W r i t e ( 2 5 , LOW) ; // A u x i l i a r y H y d r a u l i c A c t i v a t i o n
s w i t c h Low ( DSub−43) NOTE: not i n v e r s e s , but both cannot
be e n a b l e d a t t h e same time . A t h r e e s t a t e s w i t c h
d i g i t a l W r i t e ( 2 7 , LOW) ; // Detent Switch ( DSub−45)

// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// I g n i t i o n and E−Stop
d i g i t a l W r i t e ( 2 9 , LOW) ; //E−Stop d i s a b l e d v i a h i g h s i g n a l ( DSub
−35) ( r e q u i r e s a low p u l s e t o r e s e t i f something o c c u r s )
d i g i t a l W r i t e ( 3 0 , LOW) ; // S t a r t I g n i t i o n Hold f o r a t l e a s t 5
s e c o n d s ( DSub−48)

// Port C 30 through 37 ( backwards )

// ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// Right s i d e s w i t c h s e t
d i g i t a l W r i t e ( 3 2 , LOW) ; // Speed management (DSub−26)
d i g i t a l W r i t e ( 3 4 , LOW) ; // Speed C o n t r o l h i g h (+) ( DSub−27)
d i g i t a l W r i t e ( 3 6 , LOW) ; // Speed C o n t r o l low (−) ( DSub−28)
NOTE: not i n v e r s e s , but both cannot be e n a b l e d a t t h e
same time . A t h r e e s t a t e s w i t c h
d i g i t a l W r i t e ( 3 1 , LOW) ; // Operate / Loader Switch ( o p e r a t e ) (
DSub−12)
d i g i t a l W r i t e ( 3 3 , HIGH) ; // Operate / Loader Switch ( d i s a b l e ) (
DSub−30)
d i g i t a l W r i t e ( 3 5 , LOW) ; // Right S k i Switch High ( DSub−46)
d i g i t a l W r i t e ( 3 7 , LOW) ; // Rigth S k i Switch Low (DSub−47)
NOTE: not i n v e r s e s , but both cannot be e n a b l e d a t t h e
same time . A t h r e e s t a t e s w i t c h
}

void SendI2C ( ) {
d i g i t a l W r i t e ( 4 7 , HIGH) ; // Right Paddle Enable ( DSub−15)
d i g i t a l W r i t e ( 4 9 , HIGH) ; // L e f t Paddle Enable (DSub−14)
Wire . b e g i n T r a n s m i s s i o n ( 7 6 ) ; // t r a n s m i t t o d e v i c e #76 t h e t i
DAC u s e s t h e d e v i c e number 1 1 0 0 1 ’A1 ’ ’ A0 ’ where A1 = A0 = 0
Wire . send ( 1 6 ) ; // send c o n t r o l byte B00010000 :

89
 mode 1 , c h a n n e l A, normal power down f l a g
f i r s t = byte ( L e f t P a d d l e >>2) ;
s e c o n d = byte ( L e f t P a d d l e <<6) ;
Wire . send ( f i r s t ) ; // send data 1 byte x
Wire . send ( s e c o n d ) ; // send data 2 byte B11000000
Wire . e n d T r a n s m i s s i o n ( ) ; // s t o p transmitting

Wire . b e g i n T r a n s m i s s i o n ( 7 6 ) ;
Wire . send ( 1 8 ) ; // send c o n t r o l byte B00010010 :
mode 1 , c h a n n e l B, normal power down f l a g
f i r s t = byte ( RightPaddle >>2) ;
s e c o n d = byte ( RightPaddle <<6) ;
Wire . send ( f i r s t ) ; // send data 1 byte x
Wire . send ( s e c o n d ) ; // send data 2 byte B11000000
Wire . e n d T r a n s m i s s i o n ( ) ; // s t o p t r a n s m i t t i n g
d i g i t a l W r i t e ( 4 7 , LOW) ; // Right Paddle d i s a b l e (DSub−15)
d i g i t a l W r i t e ( 4 9 , LOW) ; // L e f t Paddle d i s a b l e ( DSub−14)
}

ISR ( TIMER5 CAPT vect ) {

OCR5A = ICR5 + 3 2 0 ; // 1 6 0 ; / / 4 4 6 ; // s e t h i g h o r low a f t e r 10
us
j = 0;
OCData = JoyData [ j ] ;
TimerRegA = Mask & OCData ;
TimerRegA = TimerRegA >> 1 ; // S h i f t r i g h t
TimerRegA = TimerRegA | Mask ;
TCCR5A = TimerRegA ;
OCData = OCData << 1 ; // S h i f t t h e data l e f t , MSB f i r s t
k = 1 ; // s t a r t on s e c o n d b i t
}

ISR ( TIMER5 COMPA vect ) {

i f ( j <4){
// s e t h i g h o r low a f t e r 26 us
OCR5A += 4 2 0 ; // 4 1 9 ;
TimerRegA = Mask & OCData ;
TimerRegA = TimerRegA >> 1 ; // S h i f t r i g h t
TimerRegA = TimerRegA | Mask ;
TCCR5A = TimerRegA ;
OCData = OCData << 1 ; // S h i f t t h e data l e f t , MSB f i r s t
k++;
i f ( k>7){
k = 0 ; // s t a r t on f i r s t b i t
j ++;
OCData = JoyData [ j ] ;
}

90
 } e l s e i f ( ( j <5) ) {
TCCR5A = B10000000 ;
OCR5A += 4 1 9 ;
} else {
TCCR5A = B10000000 ;
}
}

void clearLCD ( ) {
S e r i a l 1 . p r i n t ( 0xFE , BYTE) ; //command f l a g
S e r i a l 1 . p r i n t ( 0 x01 , BYTE) ; // c l e a r command .
delay (100) ;
}

A.2.3 TX Arduino

Listing A.4: Client/Transmitter Code

/∗
∗ Web S e r v e r
∗
∗ A s i m p l e web s e r v e r t h a t shows t h e v a l u e o f t h e a n a l o g i n p u t
pins .
∗/
// S e r i a l p o r t com7
#include <E t h e r n e t . h>
#include <Wire . h> // I2C l i b r a r i e s

int i = 0 ;
boolean r e f p u l s e = 0 ;

byte mac [ ] = { 0xDE, 0xAC, 0xBE , 0xEF , 0xEF , 0xEA } ;

byte i p [ ] = { 1 6 9 , 2 5 4 , 0 , 71 } ;
byte gateway [ ] = { 1 6 9 , 2 5 4 , 0 , 1 } ;
byte subnet [ ] = { 255 , 255 , 0 , 0 } ;
byte s e r v e r [ ] = { 1 6 9 , 2 5 4 , 0 , 72 } ;

C l i e n t c l i e n t ( server , 23) ;
byte Data [ 9 ] ;
byte L o w e r B i t s L e f t P a d d l e = 0 ;
byte L o w e r B i t s R i g h t P a d d l e = 0 ;
int L e f t P a d d l e = 5 1 2 ;
int RightPaddle = 8 0 0 ;
byte JoyData [ 4 ] ;
int TimeOutCount = 0 ;
b o o l e a n Disp = true ;

91
void s e t u p ( ) {
E t h e r n e t . b e g i n ( mac , ip , gateway , s u b n et ) ;
S e r i a l 1 . begin (9600) ;
S e r i a l . begin (9600) ;
Wire . b e g i n ( ) ; // s t a r t i 2 c bus f o r r e a d i n g i n J o y s t i c k v a l u e s
clearLCD ( ) ;
Serial1 . print (” I n i t i a l i z i n g . . . ”) ;
Serial . println (” Initializing . . . ”) ;
delay (1000) ;

pinMode ( 2 2 , INPUT) ; // sets the digital pin as input

pinMode ( 2 3 , INPUT) ; // sets the digital pin as input
pinMode ( 2 4 , INPUT) ; // sets the digital pin as input
pinMode ( 2 5 , INPUT) ; // sets the digital pin as input
pinMode ( 2 6 , INPUT) ; // sets the digital pin as input
pinMode ( 2 7 , INPUT) ; // sets the digital pin as input
pinMode ( 2 8 , INPUT) ; // sets the digital pin as input

pinMode ( 2 9 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t
pinMode ( 3 0 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t

pinMode ( 3 1 , INPUT) ; // sets the digital pin as input

pinMode ( 3 2 , INPUT) ; // sets the digital pin as input
pinMode ( 3 3 , INPUT) ; // sets the digital pin as input
pinMode ( 3 4 , INPUT) ; // sets the digital pin as input
pinMode ( 3 5 , INPUT) ; // sets the digital pin as input
pinMode ( 3 6 , INPUT) ; // sets the digital pin as input
pinMode ( 3 7 , INPUT) ; // sets the digital pin as input

pinMode ( 4 0 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t
pinMode ( 4 1 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t

pinMode ( 4 5 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t
pinMode ( 4 7 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t
pinMode ( 4 9 , INPUT) ; // s e t s t h e d i g i t a l p i n a s i n p u t

PORTA = B11111111 ; // S e t up p u l l up r e s i s t o r s
PORTC = B11111111 ; // S e t up p u l l up r e s i s t o r s

JoyData [ 0 ] = 0;
JoyData [ 1 ] = 0;
JoyData [ 2 ] = 0;
JoyData [ 3 ] = 0;
JoyData [ 4 ] = ’ \0 ’ ;

UpdataData ( ) ;

92
 clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Connecting . . . ” ) ;
S e r i a l . p r i n t l n ( ” Connecting . . . ” ) ;

b o o l e a n Connected = f a l s e ;

while ( ! Connected ) {
Connected = c l i e n t . c o n n e c t ( ) ;
S e r i a l . p r i n t l n ( Connected ,DEC) ;

i f ( Connected ) {
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Connected ” ) ;
S e r i a l . p r i n t l n ( ” Connected ” ) ;
delay (1500) ;
} else {
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Connection failed ”) ;
S e r i a l . p r i n t l n ( ” Connection f a i l e d ” ) ;
delay (2500) ;
client . flush () ;
c l i e n t . stop () ;
}
}

pinMode ( 4 2 , OUTPUT) ;
setupjoystickread () ;

void l o o p ( ) {

char c ;
ReadI2C ( ) ;
UpdataData ( ) ;
i f ( c l i e n t . connected ( ) ) {
i f ( Disp ) {
clearLCD ( ) ;
S e r i a l 1 . p r i n t ( ” Sending data ” ) ;
// S e r i a l . p r i n t l n ( ” Sending data ” ) ;
Disp = f a l s e ;
}
c l i e n t . p r i n t ( 2 5 4 ,BYTE) ;
c l i e n t . p r i n t ( 2 5 4 ,BYTE) ;
f o r ( int i = 0 ; i <9; i ++){
c l i e n t . p r i n t ( Data [ i ] ,BYTE) ; // Send data c a n t send 255

93
 }
c l i e n t . p r i n t ( 2 5 3 ,BYTE) ;
c l i e n t . p r i n t ( 2 5 3 ,BYTE) ;
delay (100) ;
} else {
Disp = true ;
clearLCD ( ) ;
Serial1 . print (” Disconnecting . . . ”) ;
S e r i a l . println (” Disconnecting . . . ”) ;
client . flush () ;
c l i e n t . stop () ;
clearLCD ( ) ;
S e r i a l 1 . print ( ” Disconnected . ” ) ;
S e r i a l . p r i n t l n ( ” Disconnected . ” ) ;
c l i e n t . connect ( ) ;
}
}

void ReadI2C ( ) {
byte data1 = 0 ;
byte data1a = 0 ;
byte data2 = 0 ;
byte data2a = 0 ;

byte data3 = 0 ;
byte data3a = 0 ;
byte data4 = 0 ;
byte data4a = 0 ;

// Connect t o d e v i c e and r e q u e s t two b y t e s

Wire . requestFrom ( 3 2 , 2 ) ;
data1 = Wire . r e c e i v e ( ) ;
data2 = Wire . r e c e i v e ( ) ;
Wire . e n d T r a n s m i s s i o n ( ) ;

Wire . requestFrom ( 3 3 , 2 ) ;
data3 = Wire . r e c e i v e ( ) ;
data4 = Wire . r e c e i v e ( ) ;
Wire . e n d T r a n s m i s s i o n ( ) ;

byte Mask1 = B10000000 ;

byte Mask2 = B00000001 ;
f o r ( int m = 0 ; m<8;m++){
i f ( ( data1 & Mask1 ) != 0 ) {
data1a = data1a | Mask2 ;
}

94
 i f ( ( data2 & Mask1 ) != 0 ) {
data2a = data2a | Mask2 ;
}
i f ( ( data3 & Mask1 ) != 0 ) {
data3a = data3a | Mask2 ;
}
i f ( ( data4 & Mask1 ) != 0 ) {
data4a = data4a | Mask2 ;
}
Mask2 = Mask2 << 1 ;
Mask1 = Mask1 >> 1 ;
}
JoyData [ 0 ] = data1a ;
JoyData [ 1 ] = data2a ;
JoyData [ 2 ] = data3a ;
JoyData [ 3 ] = data4a ;
}

void UpdataData ( ) {
Data [ 0 ] = byte ( ˜PINA) ; // L e f t s i d e s w i t c h s e t and E−Stop ( 2 2 t o
29)
Data [ 1 ] = byte ( ˜PINC) ; // Right s i d e s w i t c h s e t and i g n i t i o n ( 3 0
to 37)

L e f t P a d d l e = analogRead ( 0 ) ;
RightPaddle = analogRead ( 1 ) ;

LowerBits L e f t P a d d l e = byte ( L e f t P a d d l e <<6) ;

LowerBits R i g h t P a d d l e = byte ( RightPaddle <<6) ;
Data [ 2 ] = byte (PING<<6) ; // Horn and f l o a t (PG1−b i t 7 and PG0−b i t
6)
Data [ 2 ] = Data [ 2 ] | ( L o w e r B i t s L e f t P a d d l e >>2) ; // ( b i t 5 , b i t 4 )
Data [ 2 ] = Data [ 2 ] | ( L ow e rB i ts R ig h tP a dd le >>4) ; // ( b i t 3 , b i t 2 )

Data [ 3 ] = byte ( L e f t P a d d l e >>2) ;

Data [ 4 ] = byte ( RightPaddle >>2) ;

Data [ 5 ] = JoyData [ 0 ] ; // f i r s t byte

Data [ 6 ] = JoyData [ 1 ] ; // s e c o nd byte
Data [ 7 ] = JoyData [ 2 ] ; // t h i r d byte
Data [ 8 ] = JoyData [ 3 ] ; // f o u r t h byte
}

void s e t u p j o y s t i c k r e a d ( ) {
DDRL = B00101000 ; // S e t s t h e Data d i r e c t i o n r e g i s t e r o f
p o r t L ( p i n 44 p l 5 (C) & p i n 46 ( PL3 ) (A) a r e ” output ”
compare , p i n 48 ( PL1 ) i s an ” i n p u t ” )

95
 TCCR5A = B11001100 ; // ( t i m e r 5 c o n t r o l r e g i s t e r A) s e t output
compare f o r A and C, e n a b l e ” normal ” waveform g e n e r a t i o n
mode
TCCR5B = B00000010 ; // ( t i m e r 5 c o n t r o l r e g i s t e r B) e n a b l e ”
normal ” waveform g e n e r a t i o n mode , s e t t h e p r e s c a l e r t o 8 ;
TIMSK5 = B00001010 ; // e n a b l e OC ISR A and C
s e i ( ) ; // e n a b l e i n t e r u p t s
}

void clearLCD ( ) {
S e r i a l 1 . p r i n t ( 0xFE , BYTE) ; //command f l a g
S e r i a l 1 . p r i n t ( 0 x01 , BYTE) ; // c l e a r command .
delay (100) ;
}

ISR ( TIMER5 COMPA vect ) { // r e f e r e n c e p u l s e p i n 46

i f ( r e f p u l s e ) { // keep low f o r 242 us ( aka s e t h i g h a f t e r 242 us )
OCR5A += 4 8 4 ; // 242 us
OCR5C = OCR5A + 6 0 ; // i n 242 + 30 us e x t r a from OCR5A
TCCR5A = B11000100 ; // s e t A h i g h & C t o t o g g l e a f t e r each
output compare match
i = 0;
d i g i t a l W r i t e ( 4 2 , HIGH) ;
} e l s e { // keep h i g h f o r 25 ms ( aka s e t low a f t e r 25 ms)
OCR5A += 5 0 0 0 ; // 25 ms
TCCR5A = TCCR5A & B10001100 ; // s e t low
}
refpulse = ! refpulse ;
}

ISR ( TIMER5 COMPC vect ) { // c r e a t e c l o c k p u l s e p i n 44

OCR5C += 2 6 ;
i ++;
i f ( i >32){ // one e x t r a p u l s e f o r t h e s t o r a g e r e g i s t e r
TCCR5A = TCCR5A | B00001100 ; // s e t comp C h i g h
}
i f ( i == 3 7 ) {
d i g i t a l W r i t e ( 4 2 , LOW) ;
}
}

A.2.4 AMR Server

Listing A.5: AMR Signal Strength Navigation Server Code

96
import sys
import os
import time
import threading
import socket
import java . net

s t r i p m a c = lambda x : x . upper ( ) . r e p l a c e ( ’ : ’ , ’ ’ )

j a v a a p i = ’ bcapi −10.08 −5319. j a r ’

c u r d i r = o s . getcwd ( )
b c a p i p a t h = o s . path . j o i n ( c u r d i r , j a v a a p i )

c l a s s BreadCrumb ( t h r e a d i n g . Thread ) :
def init ( self ) :
t h r e a d i n g . Thread . init ( self )
s e l f . r u n n i n g = True
s e l f . l o c k = t h r e a d i n g . Lock ( )
s e l f . r s s i = { ’ l e a d e r ’ : −1 , ’ f o l l o w e r ’ : −1}
s e l f . a v g r s s i = { ’ l e a d e r ’ : −1 , ’ f o l l o w e r ’ : −1}
s e l f . leaderRSS = [ 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ]
s e l f . followerRSS = [ 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ]
s e l f . move = F a l s e
s e l f . distance = 0.0
s e l f . n b r d a t a p n t s = 0 #The number o f data p o i n t s from
stopping l a s t

def AMR moving ( s e l f ) :

s e l f . lock . acquire ()
print ’ Moving ’
#s e l f . move = F a l s e
s e l f . lock . release ()

def AMR stopped ( s e l f ) :

s e l f . lock . acquire ()
print ’ Stopped ’
s e l f . nbr data pnts = 0
s e l f . move = F a l s e
s e l f . distance = 0.0
s e l f . lock . release ()

def set My IP ( s e l f , MIP) :

s e l f . My address = MIP

def s e t L e a d e r I P ( s e l f , LIP ) :

97
 s e l f . l e a d e r a d d r e s s = LIP

def s e t F o l l o w e r I P ( s e l f , FIP ) :
s e l f . f o l l o w e r a d d r e s s = FIP

def s t o p ( s e l f ) :
””” Stop t h e t h r e a d e x e c u t i o n . ”””
s e l f . running = False

def run ( s e l f ) :
s e l f . leader info = s e l f . get info ( s e l f . leader address )
self . follower info = self . get info ( self . follower address )
s e l f . m y i n f o = s e l f . g e t i n f o ( s e l f . My address )

print s e l f . l e a d e r i n f o
print s e l f . f o l l o w e r i n f o
print s e l f . m y i n f o
s e s s i o n = s e l f . g e t s e s s i o n ( s e l f . My address )
#f = open ( ’ l o g s / r a j a n t . l o g ’ , ’w ’ )
while s e l f . r u n n i n g :
s e l f . n b r d a t a p n t s += 1
print s e l f . n b r d a t a p n t s
s e l f . get data ( session )
s e l f . leaderRSS [ s e l f . n b r d a t a p n t s %10] = s e l f . r s s i [ ’
leader ’ ]
s e l f . f o l l o w e r R S S [ s e l f . n b r d a t a p n t s %10] = s e l f . r s s i [ ’
follower ’ ]
i f s e l f . nbr data pnts > 10:
s e l f . leaderRSS = map( i n t , s e l f . leaderRSS )
s e l f . f o l l o w e r R S S = map( i n t , s e l f . f o l l o w e r R S S )
print s e l f . a v g r s s i [ ’ l e a d e r ’ ] , ” ” , s e l f .
avg rssi [ ’ follower ’ ]
s e l f . a v g r s s i [ ’ l e a d e r ’ ] = f l o a t ( sum ( s e l f .
leaderRSS ) ) / l e n ( s e l f . leaderRSS )
s e l f . a v g r s s i [ ’ f o l l o w e r ’ ] = f l o a t ( sum ( s e l f .
followerRSS ) ) / len ( s e l f . followerRSS )
i f ( abs ( s e l f . a v g r s s i [ ’ l e a d e r ’ ]− s e l f . a v g r s s i [ ’
f o l l o w e r ’ ] ) >4) : # i f t h e SNR d i f f i s g r e a t e r
than 8dB
s e l f . d i s t a n c e = ( s e l f . a v g r s s i [ ’ l e a d e r ’ ]− s e l f
. a v g r s s i [ ’ f o l l o w e r ’ ] ) ∗( −4.78)
s e l f . move = True
time . s l e e p ( 3 )
session . close ()
#f . c l o s e ( )

def g e t d a t a ( s e l f , s e s s i o n ) :

98
 i f s e s s i o n == None :
s e l f . stop ()
return
msg = b c a p i . m e ss aging . GetMessage ( )
c m d l e a d e r = ’ RADIO PEER %s 0 %s RSSI ’ % \
( s e l f . leader info [ ’ radioid ’ ] ,
s t r i p m a c ( s e l f . l e a d e r i n f o [ ’ radio MAC ’ ] ) )
c m d f o l l o w e r = ’ RADIO PEER %s 0 %s RSSI ’ % \
( s e l f . follower info [ ’ radioid ’ ] ,
s t r i p m a c ( s e l f . f o l l o w e r i n f o [ ’ radio MAC ’ ] ) )
msg . g e t ( c m d l e a d e r )
msg . g e t ( c m d f o l l o w e r )
s e s s i o n . send ( msg ) #c a t c h e x c e p t i o n h e r e
response = s e s s i o n . recv ()
r s s i l e a d e r = response . getProperty ( cmd leader )
i f r s s i l e a d e r i s not None :
rssi leader = rssi leader . strip ()
r s s i f o l l o w e r = response . getProperty ( cmd follower )
i f r s s i f o l l o w e r i s not None :
r s s i f o l l o w e r = r s s i f o l l o w e r . strip ()
#p r i n t ’ Leader : %s Base S t a t i o n : %s ’ % ( r s s i l e a d e r ,
rssi base station )

self . lock . acquire ()

self . r s s i [ ’ leader ’ ] = rssi leader
self . rssi [ ’ follower ’ ] = rssi follower
self . lock . release ()

def g e t r s s ( s e l f ) :
s e l f . lock . acquire ()
d = s e l f . r s s i [ ’ leader ’ ] , s e l f . r s s i [ ’ follower ’ ]
s e l f . lock . release ()
return d

def g e t i n f o ( s e l f , a d d r e s s ) :
session = s e l f . g e t s e s s i o n ( address )
i f s e s s i o n == None :
s e l f . stop ()
return
msg = b c a p i . m e ss aging . GetMessage ( )
msg . g e t ( ’ ETHS ’ )
msg . g e t ( ’ RADIOS ’ )
s e s s i o n . send ( msg ) #c a t c h e x c e p t i o n h e r e
response = s e s s i o n . recv ()
r a d i o i d = r e s p o n s e . g e t P r o p e r t y ( ’ RADIOS ’ ) . s t r i p ( )
e t h i d = r e s p o n s e . g e t P r o p e r t y ( ’ ETHS ’ ) . s t r i p ( )
msg = b c a p i . m ess aging . GetMessage ( )

99
 cmd1 = ’ ETH %s ’ % e t h i d
cmd2 = ’ RADIO %s ’ % r a d i o i d
msg . g e t ( cmd1 )
msg . g e t ( cmd2 )
s e s s i o n . send ( msg ) #c a t c h e x c e p t i o n h e r e
response = s e s s i o n . recv ()
eth MAC = r e s p o n s e . g e t P r o p e r t y ( cmd1 ) . s t r i p ( )
radio MAC = r e s p o n s e . g e t P r o p e r t y ( cmd2 ) . s t r i p ( )
session . close ()
info = { ’ radioid ’ : radioid ,
’ ethid ’ : ethid ,
’ eth MAC ’ : eth MAC ,
’ radio MAC ’ : radio MAC ,
}
return i n f o

def g e t s e s s i o n ( s e l f , a d d r e s s ) :
u s e r = ’ admin ’
password =b c a p i . SimplePasswordSource ( ’ breadcrumb−admin ’ )
p o r t = b c a p i . BreadCrumbSessionFactory .DEFAULT PORT
s f a c t = b c a p i . BreadCrumbSessionFactory ( ’ Rajant S e r v e r ’ )
s e s s i o n = s f a c t . c r e a t e S e s s i o n ( java . net . Inet4Address .
getByName ( a d d r e s s ) ,
port , u s e r , password )
try :
s e s s i o n . connect (5000)
except :
print ’ E r r o r c o n n e c t i n g t o t h e breadcrumb ’ , a d d r e s s
return None
else :
return s e s s i o n

if name == ” m a i n ” :
s y s . path . append ( b c a p i p a t h )
import com . r a j a n t . b c a p i a s b c a p i

Leader IP Address = ’ 169.254.0.203 ’

My IP Address = ’ 1 6 9 . 2 5 4 . 0 . 2 0 2 ’
Follower IP Address = ’ 169.254.0.201 ’

bc = BreadCrumb ( )
bc . set My IP ( My IP Address )
bc . s e t L e a d e r I P ( L e a d e r I P A d d r e s s )
bc . s e t F o l l o w e r I P ( F o l l o w e r I P A d d r e s s )
bc . setDaemon ( True )
bc . s t a r t ( )

100
 print ’ Connecting t o t h e R a j a n t s . . ’
time . s l e e p ( 2 1 )

HOST = ’ l o c a l h o s t ’
PORT = 50007
s = s o c k e t . s o c k e t ( s o c k e t . AF INET , s o c k e t .SOCK STREAM)
s . bind ( (HOST, PORT) )
print ’ Waiting f o r a s o c k e t c l i e n t ( c o n n e c t c l i e n t now ) . . . ’
s . l i s t e n (1)
conn , addr = s . a c c e p t ( )
print ’ Connected by ’ , addr
while 1 :
conn . send ( s t r ( l e n ( s t r ( i n t ( i n t ( bc . d i s t a n c e ) ) ) ) ) )
conn . send ( s t r ( i n t ( i n t ( bc . d i s t a n c e ) ) ) )

conn . send ( s t r ( l e n ( s t r ( i n t ( bc . move ) ) ) ) )

conn . send ( r e p r ( i n t ( bc . move ) ) )

conn . send ( s t r ( l e n ( s t r ( bc . r s s i [ ’ l e a d e r ’ ] ) ) ) )
conn . send ( s t r ( bc . r s s i [ ’ l e a d e r ’ ] ) )

conn . send ( s t r ( l e n ( s t r ( bc . r s s i [ ’ f o l l o w e r ’ ] ) ) ) )
conn . send ( s t r ( bc . r s s i [ ’ f o l l o w e r ’ ] ) )

conn . send ( s t r ( l e n ( s t r ( bc . a v g r s s i [ ’ l e a d e r ’ ] ) ) ) )
conn . send ( s t r ( bc . a v g r s s i [ ’ l e a d e r ’ ] ) )

conn . send ( s t r ( l e n ( s t r ( bc . a v g r s s i [ ’ f o l l o w e r ’ ] ) ) ) )
conn . send ( s t r ( bc . a v g r s s i [ ’ f o l l o w e r ’ ] ) )

S t a t u s = conn . r e c v ( 1 )
i f not S t a t u s : break
i f ( S t a t u s == ’ 1 ’ ) :
bc . AMR moving ( )
e l i f ( S t a t u s == ’ 2 ’ ) :
bc . AMR stopped ( )
time . s l e e p ( 1 )

conn . c l o s e ( )
bc . s t o p ( )

A.3 IP Routing Table

The two microprocessors communicate via the Ethernet/Wi-Fi channel using TCP
protocol under port 80. The IP configuration is static and matches a pattern accord-
ing to the location of devices.

101
IP Configuration is set up using the common template.
IP address: 169.254.x1.x2
Subnet Mask: 255.255.0.0

Where ”x1” refers to the number designated for each vehicle or base station (group
number)
001 - Base Station
002 - Bobcat
003 - Golf cart 1
004 - Golf cart 2
005 - Golf cart 3
006 - Baja

Where ”x2” refers to the device number within that particular group
100 - Network hub (if used)
101 - Rajant Breadcrumb
110 to 119 - Network cameras
120 to 129 - Network computers/devices

102
A.4 Original Pinout

Table A.1: Paddle Pinout

Paddle Pinout
Pin #, Color D-Sub Pin # (Left Paddle) D-Sub Pin # (Right Paddle)
1, N.A.
2, Red (Power) 50 50
3, Purple (A Out) 40 7
4, Black (GND) 49 49
5, Green (D Out) 14 15
6, Green (D Out) 14 15
7, Red (Power) 50 50

Table A.2: E-Stop Pinout

E-Stop Pinout
Pin #, Color D-Sub Pin # Description
2, Yellow 1 33 3.3 V power supply
2, Yellow 2 To LED board CN1 pin 4 3.3 V power supply for LED board
1, Brown 35 E-Stop enable

Table A.3: Joysticks Common Pinout

Joysticks Common Pinout

Pin #, Color D-Sub Pin # Description
1, Brown 18 +10V power supply
2, N.A
3, Orange 16 GND
4, Yellow 4 Data out (OC)
5, Green 20 Ref. clock
6, Blue 37 Ref. pulse (Ic)

103
 Table A.4: Joystick 1 Pinout

Joystick 1 Pinout
Pin #, Color D-Sub Pin # Description
1, Blue 29 Horn 3.3 V
2, N.A
3, Yellow 8 Horizontal joystick on (not needed)
4, Brown 9 Vertical joystick on (not needed)

Table A.5: Joystick 1 Pinout

Joystick 1 Pinout
Pin #, Color D-Sub Pin # Description
1, Red 25 Float bucket 3.3 V (on)
2, N.A
3, Yellow 10 Horizontal joystick on (not needed)
4, Brown 11 Vertical joystick on (not needed)

104
A.5 Modified TX Pinout

Table A.6: Transmitter Wiring Diagram

Modified Transmitter Wiring Diagram

Device Microprocessor Pin #
Right Paddle Enable Digital: 47
Left Paddle Enable Digital: 49
Horn Digital: 40
Bucket Float Digital: 41
Ignition Digital: 30
E-Stop Digital: 29
Left Paddle Analog in Analog: 0
Right Paddle Analog in Analog: 1
Joystick Ref. Pulse (Output Comp) N.A. I2C (SDA, SCL)
Joystick PCM Signal (Input Cap) N.A. I2C (SDA, SCL)
Speed Management Switch Digital: 32
Detent Switch Digital: 27
Left Ski Switch (Up) Digital: 22
Left Ski Switch (Down) Digital: 24
Right Ski Switch (Up) Digital: 35
Right Ski Switch (Down) Digital: 37
Park Brake Switch (Up) Digital: 26
Park Brake Switch (Down) Digital: 28
Aux, Hydraulic Switch (Up) Digital: 23
Aux, Hydraulic Switch (Down) Digital: 25
Speed Control Switch (Up) Digital: 34
Speed Control Switch (Down) Digital: 36
Loader Switch (Up) Digital: 31
Loader Switch (Down) Digital: 33

105
A.6 Modified RX Pinout

106
 Table A.7: Receiver Wiring Diagram

Modified Receiver Wiring Diagram

Device DSub Pin # Micro Pin #, Col, Jump # PCB Jump #, Col
Right Paddle Enable 15 Digital: 47
Left Paddle Enable 14 Digital: 49
Horn 29 Digital: 40
Bucket Float 25 Digital: 41
Ignition 48 Digital: 30
E-Stop 35 Digital: 29
Left Paddle Analog Out 40 N.A. I2C DAC (SDA, SCL)
Right Paddle Analog Out 7 N.A. I2C DAC (SDA, SCL)
Joy Ref Pulse (Input Cap) 37 Digital: 48
Joy PCM Signal (Output Comp) 4 Digital: 46
Speed Management Switch 26 Digital: 32, Black, J11 J1, Grey
Detent Switch 45 Digital: 27, Purple, J10 J2, Green
Left Ski Switch (Up) 41 Digital: 22, Brown, J11 J2, White
Left Ski Switch (Down) 42 Digital: 24, Red, J11 J2, Black
Right Ski Switch (Up) 46 Digital: 35, Green, J11 J1, Orange
Right Ski Switch (Down) 47 Digital: 37, Blue, J11 J1, Yellow
Park Brake Switch (Up) 31 Digital: 26, Orange, J10 J2, Brown
Park Brake Switch (Down) 13 Digital: 28, Yellow, J11 J2, Red
Aux, Hydraulic Switch (Up) 44 Digital: 23, Green, J10 J2, Orange
Aux, Hydraulic Switch (Down) 43 Digital: 25, Blue, J10 J2, Yellow
Speed Control Switch (Up) 27 Digital: 34, Brown, J11 J1, White
Speed Control Switch (Down) 28 Digital: 36, Red, J11 J1, Black
Loader Switch (Up) 12 Digital: 31, Orange, J11 J1, Brown
Loader Switch (Down) 30 Digital: 33, Yellow, J11 J1, Red