A TELEOPERATION AND AUTONOMOUS CAPABLE MODULAR …
Transcript of A TELEOPERATION AND AUTONOMOUS CAPABLE MODULAR …
A TELEOPERATION AND AUTONOMOUS CAPABLE
MODULAR ROBOT ARCHITECTURE
AND IMPLEMENTATION
by
DAVID CHRISTOPHER SANDEL
KENNETH G. RICKS, COMMITTEE CHAIRDAVID J. JACKSON
MONICA D. ANDERSON
A THESIS
Submitted in partial fulfillment of the requirements for the degreeof Master of Science in the Department of
Electrical and Computer Engineeringin the Graduate School of
The University of Alabama
TUSCALOOSA, ALABAMA
2015
Copyright David Christopher Sandel 2015ALL RIGHTS RESERVED
ABSTRACT
Robots are an integral part of contemporary society with ever increasing use in re-
source collection, industrial, military, and exploration-based applications. The degree of hu-
man intervention necessary for a robot to successfully operate varies from system to system
and depends heavily on the application, resources available, and knowledge of the opera-
tional environment. A system that can operate either autonomously or under control of a
human operator provides the flexibility to adapt to the requirements of a specific mission
and to unexpected situations as they are encountered. Similarly, a platform that can be
quickly and easily modified is capable of being utilized in a larger number of applications.
This thesis describes a generalized computational architecture for a robotic platform
that allows the system to be either teleoperated by a remote human operator or completely
autonomous. In addition, the architecture is designed specifically to support a modular
platform upon which various modules can be attached or removed to provide the functionality
needed to complete specific tasks. This architecture was implemented on the University of
Alabama Modular Autonomous Robotic Terrestrial Explorer (MARTE) platform as part
of the 2014 NASA Robotic Mining Competition to ultimately result in a robot capable of
collecting and delivering regolith in a simulated lunar or Martian environment. MARTE was
successfully used at the competition and demonstrated the capabilities of the architecture
both during testing and in the competition environment.
ii
LIST OF ABBREVIATIONS AND SYMBOLS
ADC Analog-to-Digital Converter
AHRS Attitude and Heading Reference System
API Application Programming Interface
ASCII American Standard Code for Information Interchange
ATLANTIS A Three-Layer Architecture for Navigating Through IntricateSituations
ATV All-Terrain Vehicle
AuRA Autonomous Robot Architecture
BLE Bucket Ladder Excavator
CLARAty Coupled Layer Architecture for Robotic Autonomy
CPU Central Processing Unit
DC Direct Current
DS-1 Deep Space One
DSSA Domain Specific Software Architecture
FTDI Future Technology Devices International
GUI Graphical User Interface
I/O Input/Output
IEEE Institute of Electrical and Electronics Engineers
IMU Inertial Measurement Unit
IP Internet Protocol
LED Light Emitting Diode
LiPo Lithium Polymer
MARTE Modular Autonomous Robotic Terrestrial Explorer
MCP MARTE Control Protocol
iii
NASA National Aeronautics and Space Administration
NASREM NASA/NBS Standard Reference Model
NBS National Bureau of Standards
NIST National Institute of Standards and Technology
NMRA New Millennium Remote Agent
OS Operating System
POSIX Portable Operating System Interface
PWM Pulse Width Modulation
RAMP Robotic Architecture for a Modular Platform
RANSAC Random Sample Consensus
RAP Reactive Action Package
RMC Robotic Mining Competition
ROS Robot Operating System
RS Reactive System
SBC Single Board Computer
SCIP Sensor Communication Interface Protocol
SSS Servo Subsumption Symbolic
TCA Task Control Architecture
TCP Transmission Control Protocol
TTL Transistor-Transistor Logic
UDP User Datagram Protocol
USB Universal Serial Bus
iv
ACKNOWLEDGMENTS
First, I’d like to thank everyone involved in the University of Alabama Astrobotics
team and whom took part in the development of MARTE.
1. Caleb Leslie for acting as team lead and for helping design and implement all aspects
of the MARTE platform including the power distribution and electronics boxes;
2. Michael Carswell and the Base group for implementing the Base platform, the Base
and Autonomy electronics boxes, and the Autonomy sensor mounts;
3. Kellen Schroeter and the Module group for implementing the Bucket Ladder Excava-
tor platform and electronics box;
4. Andrew Faulkner for co-leading the Software group with me, his AHRS, gimbal, obsta-
cle detection, and path planning algorithms, and for helping set up the communication
link;
5. Mitchell Spryn, Derrill Koelz, and the rest of the Software group for their assistance
in implementing various components of the Backend, Frontend, and Autonomy sub-
systems;
6. Andrew Price for collaborating with me to design the original MARTE Control Pro-
tocol and for developing the original Frontend application;
7. Justin Headley for leading the past University of Alabama Lunabotics teams and
reviewing my thesis draft.
I’d also like to thank Dr. Ricks for all of his support as my advisor, teacher, and the advisor
of the Astrobotics team, Dr. Jackson and Dr. Anderson for the knowledge they have passed
down to me in their classes, and my family for all of their support.
v
CONTENTS
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
LIST OF ABBREVIATIONS AND SYMBOLS . . . . . . . . . . . . . . . . . . . . . iii
ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Control Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Teleoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Deliberative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Reactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3 Hybrid Deliberative/Reactive . . . . . . . . . . . . . . . . . . . . . . 7
3. RELATED WORKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Teleoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
vi
3.3.1 Deliberative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Reactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3 Hybrid Deliberative/Reactive . . . . . . . . . . . . . . . . . . . . . . 13
4. GENERAL ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. Architecture Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6. Subsystem Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6.2 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5. CASE STUDY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1. NASA Robotic Mining Competition . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. MARTE Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Base Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.2 Bucket Ladder Excavator Module . . . . . . . . . . . . . . . . . . . . 35
5.3. RAMP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.1 Subsystem Communication . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.2.2 BLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.3 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
vii
5.3.4 Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6. CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
viii
LIST OF TABLES
5.1 MARTE Robot Distribution Layer Requests . . . . . . . . . . . . . . . . . . 48
5.2 MARTE Robot Distribution Layer Module List Response . . . . . . . . . . . 48
5.3 MARTE Base Module Distribution Layer Requests . . . . . . . . . . . . . . 50
5.4 MARTE Base Module Distribution Layer Get Responses . . . . . . . . . . . 51
5.5 MARTE BLE Module Distribution Layer Requests . . . . . . . . . . . . . . 55
5.6 MARTE BLE Module Distribution Layer Get Responses . . . . . . . . . . . 55
5.7 NASA RMC Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ix
LIST OF FIGURES
2.1 Human Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Basic Teleoperation Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Deliberative Autonomous Paradigm . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Reactive Autonomous Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Hybrid Autonomous Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 System Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Backend Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Frontend Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 Autonomy Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Teleoperated Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 Autonomy Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1 RMC Arena Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 MARTE (Base and BLE Modules) . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 MARTE Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 MARTE Base Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 MARTE Bucket Ladder Excavator Module . . . . . . . . . . . . . . . . . . . 35
5.6 Subsystem Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.7 MARTE Control Protocol Request Message . . . . . . . . . . . . . . . . . . 38
x
5.8 Request Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.9 MARTE Control Protocol Response Message . . . . . . . . . . . . . . . . . . 39
5.10 Response Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.11 MARTE Teleoperation Inter-Subsystem Communication . . . . . . . . . . . 40
5.12 MARTE Autonomy Inter-Subsystem Communication . . . . . . . . . . . . . 41
5.13 MARTE Backend Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.14 Phidgets PhidgetSBC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.15 Linksys WRT54G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.16 MARTE Communication Hardware Layer . . . . . . . . . . . . . . . . . . . 45
5.17 MARTE Server Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.18 MARTE Hardware Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.19 MARTE Base Functional Layer: Base Drive . . . . . . . . . . . . . . . . . . 51
5.20 MARTE Base Functional Layer: Wheel Drive . . . . . . . . . . . . . . . . . 52
5.21 MARTE Base Functional Layer: Voltage System . . . . . . . . . . . . . . . . 53
5.22 Sabertooth 2X60 Motor Controller . . . . . . . . . . . . . . . . . . . . . . . 54
5.23 MARTE BLE Functional/Hardware Layers . . . . . . . . . . . . . . . . . . . 57
5.24 MARTE Frontend Functional Layer: Status Update . . . . . . . . . . . . . . 60
5.25 MARTE Frontend Functional Layer: From Mapping . . . . . . . . . . . . . . 60
5.26 Microsoft Xbox 360 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.27 Hokuyo UTM-30LX-EW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.28 SPT200 Pan & Tilt System . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.29 Hitec HS-5465MG Servo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.30 Phidgets PhidgetSpatial 3/3/3 Sensor . . . . . . . . . . . . . . . . . . . . . . 64
xi
5.31 VIA EPIA-P900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.32 MARTE Autonomy Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.33 MARTE Autonomy Functional Layer: Autonomy Hardware . . . . . . . . . 68
5.34 MARTE Autonomy Functional Layer: All Hardware . . . . . . . . . . . . . . 69
5.35 MARTE Autonomy State Machine . . . . . . . . . . . . . . . . . . . . . . . 71
5.36 MARTE Final Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.37 Autonomy Testing on the Test Base Module . . . . . . . . . . . . . . . . . . 73
5.38 Run #5: Localization Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.39 Run #5: Localization Result . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.40 Run #5: Path Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.41 Run #5: Autonomously Crossing . . . . . . . . . . . . . . . . . . . . . . . . 78
5.42 Run #3: Autonomously Digging . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.43 Run #3: Autonomously Unloading . . . . . . . . . . . . . . . . . . . . . . . 80
xii
CHAPTER 1
INTRODUCTION
Robots are used in a wide variety of applications in modern society. They remove
the need for human intervention in repetitive tasks and handle processes that require precise
actions such as those in industrial manufacturing. They also provide us the chance to observe
and explore environments that are risky or dangerous to human health, such as the deep
oceans or other planets [1], [2]. In many such applications, it can be beneficial to have a
modular platform that can be quickly and easily modified to adapt to one of a multitude of
tasks. This is particularly true for robotic systems used in space exploration. The amount of
mass and space available aboard rockets carrying equipment from Earth’s surface to orbit and
beyond is extremely limited. A modular platform would lessen the amount of mass necessary
to transport in the long run. When new tasks arise, instead of requiring a completely new
system, only a new module would be needed. This module would then be interfaced to an
existing platform to carry out the task.
1.1 Objective
This thesis introduces a general computational architecture for a robotic platform
that meets two requirements:
1. The architecture will support implementation on a platform composed of many po-
tential modular attachments that can be added and removed;
2. The architecture will support control of the platform through either a remote operator
(teleoperation) or by an optional, fully-autonomous control module.
This scalable architecture allows the functionality of the robotic system to be modified or
extended by changing or adding to the modules attached. In addition, by allowing both
1
teleoperated or autonomous control, a teleoperated system can be later automated when
such a subsystem is developed or an autonomous system can be overridden by a human
operator when the need arises.
The designed architecture, henceforth called the Robotic Architecture for a Modular
Platform (RAMP), was implemented on the University of Alabama Modular Autonomous
Robotic Terrestrial Explorer (MARTE) platform to provide a system for the excavation and
retrieval of simulated lunar/Martian regolith as part of the 2014 NASA Robotic Mining
Competition (RMC). It was implemented using two modules, a drive train module and
excavation module, and can operate autonomously through an optional subsystem.
1.2 Thesis Outline
This thesis is arranged into six chapters. Chapter 2 begins with a summary of relevant
background information on teleoperated and autonomous robotic architectures to provide a
foundation for the work that will be presented. Chapter 3 describes some existing robotic
architectures from related projects and places RAMP in context. Chapter 4 details the
generalized architecture, RAMP, and components that will support both teleoperated and
autonomous control of a modular robotic platform. Chapter 5 describes an implementation
of RAMP on the University of Alabama MARTE platform as part of the 2014 NASA RMC
and includes a discussion of the results of this implementation. Finally, Chapter 6 concludes
with a summarization of the work presented and a brief discussion on potential future work
related to the architecture and implementation.
2
CHAPTER 2
BACKGROUND
It is beneficial to cover some basic background information on the standard approaches
to robotic architectures. This chapter provides a refresher on the various levels of human
interaction involved in robot control followed by the basic teleoperation and autonomous
architecture paradigms.
2.1 Control Schemes
The control of a robotic platform can be classified by the degree of human involvement
required for the system to carry out its tasks. This can be represented as a scale of levels of
interaction as shown in Figure 2.1.
Human Operated AutonomousSemi-Autonomous
Figure 2.1: Human Interaction
At the left end of the scale reside systems that require a human operator to make
all high-level decisions about the tasks necessary to complete a goal and, additionally, the
specific actions the platform needs to carry out in order to accomplish that task. While
generally not considered robots, remote-controlled vehicles are a good example of these
types of systems. Take a remote controlled airplane for example. The human operator
takes in information on the environment and the airplane’s status through his/her senses,
makes a decision on what the plane needs to do next to accomplish a goal (such as to gain
altitude, land, or avoid a tree), then inputs commands via the joysticks on the controller.
The controller transmits those commands to the airplane which are used to set the voltages
3
driving the propeller motor and to rotate the servos that control the locations of the elevator,
rudder, and ailerons. The system itself makes no decisions, it only acts on the controls
provided by the operator.
At the opposing end of the scale are the fully-autonomous robots. These robots
do not need a human operator to decide which tasks should be performed to complete a
mission or the specifics on how to carry out those tasks; actions are either preprogrammed
or determined by the system while operating. For example, a quadcopter platform may carry
out a patrol mission completely autonomously. The system determines that, to complete its
mission, it needs to take off, rise to a certain altitude above the ground, follow some path
while transmitting video to a ground station, then re-land at is original starting point. In
addition to these high level tasks, it also decides what low-level control signals need to be
used to perform these actions using feedback from various sensors, such as an altimeter or
GPS to determine position and an IMU to determine the platform’s orientation.
There are many systems that do not exist at the extremes of this scale. Most
human-operated robotic platforms provide some built-in control abstraction. In the remote-
controlled airplane example, instead of the operator controlling the voltage driving the pro-
peller motor, the system could instead take in a desired airspeed from the user and, using a
airspeed sensor, control the motor voltage internally to try to preserve that airspeed. As the
system gets smarter, it may begin to offload some of the decision making from the operator
as well. For example, a lunar rover may not know how to autonomously complete a mission
to explore an area, but may be capable of autonomously planning a path, avoiding obstacles,
and driving to operator designated points. These systems are often called semi-autonomous
systems.
4
2.2 Teleoperation
For robotic systems that required human control, input can be provided either directly
or remotely. Teleoperation is a type of human control in which the human operator controls
the platform from a remote location. A basic teleoperated system consists of two separate
subsystems, named in relation to the location of the human operator: the local and remote
subsystems [1]. The relationship between these subsystems is shown in Figure 2.2.
Local
Remote
Control
Sensors
Operator
Display
Actuators
User Input
Communication Link
Status
Figure 2.2: Basic Teleoperation Architecture
The local subsystem interacts directly with the human operator and is tasked with
reading the operator’s input and providing the operator with feedback on the current status of
the overall system. The remote subsystem directly interacts with the sensors and actuators
that make up the robotic platform. The two subsystems communicate with one another
across a communication link, thus allowing the operator’s input commands to affect the
actions of the platform and for the platform to return its status and sensory information
back to be displayed to the user.
5
2.3 Autonomy
Autonomous architectures generally fall under one of three paradigms. This section
summarizes the basic concepts of each. An in-depth analysis of this topic can be found in
[1].
2.3.1 Deliberative
Sense Plan Act
Figure 2.3: Deliberative Autonomous Paradigm
The first autonomous robots were designed under the deliberative paradigm. These
systems act in a sequential manner, as shown in Figure 2.3:
1. The system senses its current state and environment;
2. The system decides upon a plan to follow based on these sensor readings and past
knowledge;
3. The system drives its actuators based on its plan before returning to collect new
sensor readings and continue the process.
The biggest disadvantage of deliberative systems is the performance bottleneck created by
the planning stage. Traditionally, planning takes a relatively large amount of processing time
compared to the other aspects of an autonomous system and, therefore, the update rate of
the system is limited by the planning stage that occurs in every iteration of the processing
loop [1].
6
2.3.2 Reactive
Sense Act
Sense Act
Sense Act
Figure 2.4: Reactive Autonomous Paradigm
The reactive paradigm evolved as a reaction to the deliberative approach. It com-
pletely forgoes an explicit planning stage, instead acting based on a collection of independent
behaviors as shown in Figure 2.4. Each behavior in a reactive system takes in sensor readings
and, depending on the behavior it represents, affects the action the robot will carry out. The
way these behaviors combine ultimately defines the operation of the overall system [1].
Reactive systems greatly improve the reaction time of autonomous systems. For ex-
ample, instead of the discrete obstacle detection and path planning steps that would occur
during each processing loop in the deliberative system, a reactive system might continuously
run an obstacle avoidance behavior that would change the direction a robot is driving when-
ever it detects an obstacle in its path. Another benefit of reactive systems is the distinction
between separate behaviors to more easily accommodate parallel processing. The key dis-
advantage is the loss of the planning stage. Instead of a subsystem which would define the
overall operation of the robot, the behaviors must be designed such that they will cooperate
to produce the desired overall operation, often not a simple task [1].
2.3.3 Hybrid Deliberative/Reactive
The hybrid paradigm attempts to reintegrate an overall planning component into the
reactive approach as shown in Figure 2.5. The hybrid approach uses behaviors for handling
reactive control and providing the basic functionality for the system. The planning compo-
nent handles the overall decision-making process and knowledge of the robot’s status and
7
Sense Act
Sense
Plan
Act
Sense Act
Figure 2.5: Hybrid Autonomous Architecture
environment. To achieve the system’s goal, the planning component activates, deactivates,
and modifies the behaviors to complete the specific tasks the robot needs to accomplish [1].
8
CHAPTER 3
RELATED WORKS
Many authors over the past decades have designed and documented various robotic
architectures and implementations. This chapter will briefly discuss a selection of these
architectures and place RAMP into context.
3.1 Frameworks
To begin, it is relevant to mention some well-known robot frameworks that assist
developers in implementation and testing of robot algorithms and software. These frame-
works provide an array of different development tools, APIs, and libraries with the goal of
supporting easier development of robotics-related functionality and code reuse across differ-
ent systems and robot platforms. In many cases, as with RAMP, robot architectures focus
less on providing specific tools and APIs. Instead, focus is directed more toward the system
structure and components needed to meet various design requirements. One popular robot
framework is the Player Project [3], [4]. It encompasses three software components: Player,
Stage, and Gazebo. Player is defined as a “robot device interface” that defines an abstraction
layer around the hardware specifics related to common robot functionality such as movement
and sensor readings. In the Player model, an instance of the Player interface is executed as
a server. This Player server hides the hardware details from other software and algorithms
that act as clients in this model. Stage and Gazebo are both simulators that implement the
Player interface. Client algorithms that utilize the Player interface need not know whether
their requests and data are being handled through simulation or by a physical platform.
The Robot Operating System (ROS) [5], like Player, is a robot framework that is designed
to provide an abstract interface around robot hardware. ROS is more complex than Player
9
and implements a message passing system for communication between nodes that provide
the various control and sensing capabilities. One benefit of ROS’s messaging system is that
it provides better support for distributed systems. RAMP shares some similarities to the
Player Project in that both are structured as client-server systems, but the overall goal of
RAMP and these two frameworks differ. The Player Project and ROS both exist to provide
the specific APIs and tools necessary to abstract away the details of hardware interaction
from algorithm implementations. This benefits developers by allowing code reuse across
different hardware and robot platforms. RAMP, instead of defining specific APIs, focuses
on what components a robot implementation will require to support both teleoperation and
autonomy on a modular platform.
3.2 Teleoperation
One existing teleoperation-based architecture for robotics was derived from domain
engineering to create a domain specific software architecture (DSSA) [6]. This DSSA is
specifically designed for use with a human operator and does not operate autonomously. This
is unlike RAMP which focuses on providing the capability of either autonomous or remote
operation. The DSSA consists of five components: Graphical Representation, Collision
Detection, User Interface, Communication, and Controller. RAMP, during teleoperation,
consists of similar components but with the User Interface and Graphical Representation
considered part of a single layer and the Collision Detection and Controller combined into
a single layer. The DSSA also differs in that it has controllers on the local system. These
controllers use operator commands to simulate the motion of the platform prior to sending
control signals across the communication link. RAMP, instead, places the controllers on
the remote side of the communication link. This means latency across the communication
link has a larger affect on DSSA and, as a result, its application focus is on slower moving
systems with soft real-time requirements [6]. The DSSA has been implemented on a variety
of platforms including a remotely operated service arm (ROSA), a pipe Inspection and
10
Retrieval Vehicle (IRV), and Teleoperated and Robotized System for Maintenance Operation
in Nuclear Power Plant Vessels (TRON) [6], [7].
The NASA/NBS Standard Reference Model (NASREM) architecture [8] is another
well-known, teleoperation architecture. It is designed for partially autonomous space station
robotic systems. NASREM is a hierarchical architecture in which high-level tasks are broken
down into low-level control. A remote operator can command the robot at various levels
of this hierarchy by sending high-level tasks or, alternatively, intervene by sending low-level
commands. It has five major components: Operator Interface, Task Decomposition, World
Modeling, Sensory Processing, and a Global Memory. A key difference between RAMP and
NASREM is that RAMP divides autonomy-related functionality into a distinct subsystem
from the robot’s low-level hardware control functions. NASREM, on the other hand, in-
tegrates autonomous functionality together with hardware control in a single system. In
RAMP, the separate autonomy subsystem communicates with the control system using the
same command interface as a remote operator would, making the autonomy subsystem a
replacement for a remote operator. Overall, this means the teleoperator cannot make use of
functionality that is part of the RAMP autonomy subsystem. The benefit of this approach is
that RAMP provides the capability to completely remove the autonomy subsystem from the
overall system without affecting the ability to teleoperate. NASREM’s integrated approach
allows a remote operator to interact with the autonomy-like functionality. However, such a
design will not allow the system to operate independent of the autonomy system without
special consideration during implementation. NASREM has been the foundation for a gen-
eral proof-of-concept teleoperatable platform [9] and a system to safely manage a landfill
[10]. The similar RAYBOT architecture [11] was implemented on a teleoperated all-terrain
vehicle (ATV).
11
3.3 Autonomy
3.3.1 Deliberative
As previously hinted, NASREM also supports autonomous operation. In this situa-
tion, a NASREM system accepts mission-level commands from a remote operator to initiate
autonomous operation and the various levels of the hierarchy provide the competent func-
tionality to decompose this mission into tasks and control to be carried out. When operating
autonomously, NASREM is an example of a deliberative autonomous architecture. The Sen-
sory Processing, World Modeling, and Task Decomposition components make up the Sense,
Plan, and Act components in the deliberative paradigm [1]. Each level of the hierarchy
must go through the sequence of sensing, then planning, then acting. During the World
Modeling (Plan) stage, the robot’s understanding of the world is modeled then actions are
simulated and potentially re-planned. Because this occurs between every sensing and acting
phase, the timing constraints on World Modeling are extremely important for components
with hard real-time requirements. RAMP, when operating autonomously, is a hybrid au-
tonomous architecture. It, along with other hybrid architectures, move the planning and
world modeling-related functionality from between sensing and acting to allow for easier
real-time control loops without sacrificing planning functionality.
3.3.2 Reactive
Subsumption [12], [13] is the most famous of reactive paradigm architectures. It
consists of a hierarchy of modular behaviors with increasing levels of competence. Each
high-level behavior can be suppressed or modified by more primitive, lower-level behaviors.
For example, a robot may contain a high-level behavior for trying to drive in some general
direction. This behavior may then be overridden by a low-level obstacle avoidance behavior
when forward-facing sensors detect an obstacle. As mentioned in the previous chapter,
reactive autonomous designs do not plan but instead are given behaviors that are combined
12
in such a way as to result in some overall desired operation. On the other hand, RAMP
and other hybrid architectures do contain a planning component. Subsumption has been
implemented on many platforms [13] for applications such as can collection [14] as well as
proof-of-concept platforms for the exploration of planetary surfaces [15].
3.3.3 Hybrid Deliberative/Reactive
RAMP, when operating autonomously, acts as a hybrid paradigm architecture. Hy-
brid architectures are a result of reintroducing the planning aspects of deliberative designs
while taking advantage of the behavior-like components of reactive architectures. Most cur-
rent work on robotic architectures is focused on hybrid designs. One of the first was the
Autonomous Robot Architecture (AuRA) [16], [17]. Originally, it was an architecture specif-
ically designed for navigation but has since been generalized for general autonomous systems.
It is divided into two major layers. The first contains the deliberative-related components
which include a hierarchical planner and a representation of the world. The second, schema
controller, layer acts as the reactive portion of the hybrid design and contains the sensing
and actuation controllers. An AuRA-based system is primarily driven by the schema con-
troller, like a reactive system. The planner is used to set up the reactive controllers when a
new mission is received or to handle any problems detected by the reactive layer. RAMP,
like many later hybrid architectures, adds a new layer between the deliberative and reactive
layers to manage their interaction. AuRA has been implemented on various robots at the
University of Massachusetts and Georgia Tech such as a trash collecting robot [16].
Another early hybrid architecture is ATLANTIS [18]. It is a three-layered design
with a Deliberator, Sequencer, and Controller. The first and last relate to the deliberative
and reactive parts of the hybrid paradigm, respectively. The Sequencer drives the system
and manages the interaction between the two other layers by monitoring the system for
problems, invoking the Deliberator when a new plan is needed, and starting/stopping the
individual activities in the Controller. This last responsibility is handled based on a list
13
of tasks modeled by the reactive action package (RAP) system [19]. The 3T architecture
[20] is a similar architecture with a Planner, Sequencer, and Skill Manager. 3T differs in
that it is driven by the upper, Planner, layer whereas ATLANTIS is driven by the middle,
Sequencer, layer. 3T has been implemented on various platforms including a robot that
can run general errands [20] and a monitoring system on the the Space Shuttle’s Remote
Manipulator System [21]. Various other architectures have used this general three-tiered
design such as the architecture described in [22] and the CoCo architecture [23].
There are a multitude of other hybrid architectures. NMRA [24] is another de-
signed for NASA’s Deep Space One (DS-1) project. NMRA heavily emphasizes real-time
constraints. CLARAty [25] is a two-tiered design that was implemented on NASA’s K9 and
K10 [26] prototype rovers. Other popular hybrid architectures include Reactive System (RS)
[27], Task Control Architecture (TCA) [28], Saphira [29], and SSS [30].
While later chapters will break RAMP down into many more than three layers, from
a high-level perspective, RAMP, when operating autonomously, is closely related to the
three-tiered hybrid architectures such as ATLANTIS and 3T. RAMP contains two layers
that are directly related in responsibility to the Deliberator/Planner and Sequencer layers
in ATLANTIS and 3T. RAMP also provides the same functionality provided by the Con-
troller/Skill Manager Layer but breaks it down into multiple smaller layers and a completely
separate subsystem. This is done to support the RAMP design requirements of a modular
robotic platform with a removable autonomy control module.
To summarize, RAMP is a robotic architecture specifically designed for a modu-
lar robotic platform that can operate either by teleoperation or via a removable, hybrid
paradigm autonomy module. There are two key distinctions between RAMP and existing
projects. First, most autonomous architectures are capable of supporting teleoperation to
some degree so that they can receive high-level mission commands, but they are either in-
capable of or require implementation-specific details to allow the autonomy components to
be removed from the system while preserving teleoperation capabilities. Secondly, most ex-
14
isting architectures do not disallow implementation on a modular platform, but also offer
no direct support for modularity. RAMP is specifically designed to support systems that
provide removable autonomy and modularity.
15
CHAPTER 4
GENERAL ARCHITECTURE
This chapter describes the generalized RAMP architecture. It starts with a high-level
overview of the system and the major subsystems required to support both teleoperated
and autonomous operation followed by an in-depth description of the components of each
subsystem and their requirements in order to support the system’s operation and a modular
platform.
4.1 System Architecture
A robotic system capable of operating in either teleoperated or autonomous modes has
three potential actors, as shown in Figure 4.1. The robotic platform is the actor common
to the system while operating in either of the two modes of operation. The platform’s
job is to provide the necessary mechanical and electrical capabilities such that the system
can act in such a way as to complete the overall mission objective. The human operator
and autonomous operator are the two decision making actors in their respective modes of
operation, each responsible for deciding how the platform should act to successfully complete
the mission.
In both modes of operation, desired actions flow from the controlling operator to
the robotic platform, which attempts to carry out those requests. This fits with a typical
client-server architecture. Here, the robotic platform takes the role of the server, accepting
commands from the clients, in this case, the operators. Information also needs to flow in the
opposite direction. To make educated decisions, the operators need to know the status of
the platform. Thus, the platform acts as a source for status information that the operators
16
HumanOperator
AutonomousOperator
RoboticPlatform
Control Control
ControlStatus
Status Status
Teleoperation Autonomous
Figure 4.1: System Actors
can consume. By requring the operators to request for a status update from the platform,
this use case also fits within the client-server architecture.
The overall computational architecture is designed based on these interactions. First,
three subsystems emerge, one for each actor: the Backend, Frontend, and Autonomy. These
relationships are summarized in Figure 4.2. Communication between the three subsystems
is modeled around a client-server architecture.
17
Frontend Autonomy
Backend
HumanOperator
RoboticPlatform
AutonomousOperator
Control Control
ControlStatus
Status Status
Teleoperation Autonomous
Figure 4.2: Subsystems
4.2 Backend
The Backend is the subsystem that manages interactions with the robotic platform.
It has three key responsibilities:
1. It must provide the server interface for accepting requests from the clients and re-
turning responses about the status of the system;
2. It must be capable of understanding the requests received and interacting with the
platform such that the platform acts appropriately based on the request;
3. It must manage the platform hardware with the necessary controllers to maintain any
desired states and avoid dangerous operations.
To meet these responsibilities, the Backend is divided into the eight layers shown in Figure
4.3.
18
Robot Distribution Layer
Module Distribution Layer
Server Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Platform Hardware Interface Layer
Platform Hardware Layer
Functional Layer
Communication Link
Robotic Platform
Module Module
Module Module
Module Module
Module Module
Module Module
Figure 4.3: Backend Architecture
The first three layers, the Communication Hardware, Communication Hardware In-
terface, and Server layers, provide the server functionality for meeting the first requirement
of the Backend. The Communication Hardware Layer encompasses any hardware necessary
19
for the modulation and demodulation of communication signals transmitted and received.
The Communication Hardware Interface Layer contains the drivers and APIs necessary for
interfacing with and using the previously mentioned communication devices. Finally, the
Server Layer provides the interface for receiving requests and sending responses. Together,
these layers determine the communication protocols the Backend will use to format messages
exchanged between the clients and Backend. The ultimate responsibility of these three layers
is to convert the communication signals received by the Backend into commands understood
by the Distribution Layer and, later, to take responses returned by the Distribution Layer
and transmit them as signals back to the client.
The Robot and Module Distribution layers are responsible for examining requests
received on the server and determining what should be done. It is at these layers that the
modularity of the robotic platform becomes important. First, the request must be examined
by the Robot Distribution Layer from an overall “robot” point of view. What modules
are necessary to carry out the request? Are the necessary modules attached and available?
What do the modules need to do to carry out the overall task? This will result in the
original request or new requests being passed to the modules involved in completing the
task. Next, each involved module’s Module Distribution Layer must examine the request to
determine what they need to do with their functionality by invoking the correct operations
in the Functional Layer. This satisfies the second requirement of the Backend.
The remaining layers, the Functional, Platform Hardware Interface, and Platform
Hardware layers, contain the functionality for interacting with the robotic platform. Like
the Module Distribution Layer, each possible module has a seperate implementation of these
layers. The Platform Hardware Layer is closely related to, and can be considered part of,
the the robotic platform. It encompasses all of the hardware necessary for actuating the
platform, sensing the status of the platform, and sensing the environment. The Platform
Hardware Interface Layer provides the drivers and API for allowing the Functional Layer
to interact with the Platform Hardware Layer. The Functional Layer provides multiple
20
benefits. First, it provides abstractions around the hardware interfaces for readability and
reusability. Whereas the Platform Hardware Interface Layer contains interfaces for low-
level hardware interaction, such as setting digital output pins, driving a PWM signal, or
reading ADC channels, the Functional Layer provides abstract wrappers, such as turning
an indicator light on or off, setting a desired servo position, or determining the position
of a linear actuator. A second benefit of the Functional Layer is to fuse the functionality
of multiple separate hardware devices, such as to combine an encoder interface and wheel
interface to result in the functionality of driving a wheel at a specific velocity. These three
layers meet the final requirement for the Backend.
4.3 Frontend
The Frontend manages the interactions of the human operator with the rest of the
system during teleoperation. Its responsibilities include:
1. Receiving and interpreting operator input;
2. Communicating the operator’s desired actions to the Backend;
3. Requesting and displaying status of the system to the operator so he/she can make
more informed decisions.
The Frontend is divided into the seven layers shown in Figure 4.4.
The bottom three layers, the Communication Hardware, Communication Hardware
Interface, and Client Layer, act as the opposing end to the three communication-related layers
of the Backend subsystem. They are responsible for exchanging the operator’s actions and
platform’s status with the Backend over the communication link. This involves formatting
the requests generated by the Frontend’s Functional Layer into the protocol expected by the
Backend, modulating the data across the communication link, demodulating any response
signals, and unpacking the data from the response to be passed back to the Functional Layer.
The Functional Layer manages the Frontend’s knowledge of the system and manages
when the Client Layer is invoked. This involves determining what functionality the Backend
21
Client Layer
Mapping Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Operator Hardware Interface Layer
Human Operator
Communication Link
Functional Layer
Operator Hardware LayerControl Display
Figure 4.4: Frontend Architecture
can provide based on the the modules attached to the robotic platform. It should also contain
a component for ensuring regular status updates are requested on behalf of the operator.
The Mapping, Operator Hardware Interface, and Operator Hardware layers exist to
interface with the human operator. The Operator Hardware Layer contains two components,
the Display component and the Control component. The Display component is the hardware
necessary to inform the user of the current status of the system. This can be as simple as
22
LED indicators or as complex as a graphical user interface (GUI). The Control component
encompasses the input devices the operator uses to control the system such as joysticks,
controllers, or a button on a GUI. The Operator Hardware Interface Layer is composed of
the drivers and APIs necessary to write to the Display hardware and read from Control
hardware.
The Mapping Layer decides how operator inputs map to different requests for the
Backend subsystem and how status received from the Backend maps to the display. A
separate layer for mapping also provides the capability of having different mapping configu-
rations for different situations or users. This is beneficial, for example, in situations where
one operator prefers different or more sensitive controls than another.
4.4 Autonomy
The Autonomy subsystem acts as the autonomous actor when the platform is oper-
ating in autonomous mode. It is divided into the eight layers in Figure 4.5.
The Communication Hardware, Communication Hardware Interface, and Client lay-
ers have the basic responsibilities as the three identically named layers in the Frontend
subsystem: to facilitate communication between the Backend and the rest of the Autonomy
subsystem. One difference is that, whereas the Frontend client will always utilize the commu-
nication link, this is not required for the Autonomy subsystem. The Autonomy subsystem
may be placed on the remote side of the communication link, putting the Autonomy subsys-
tem on the robot platform. In many cases, this is desired for the sake of avoiding potential
latency issues due to distance between the operator and platform. The alternative would
place the Autonomy subsystem on the operator side of the communication link; requiring
the link for interaction between the Autonomy and Backend subsystems.
The Autonomy Hardware and Autonomy Hardware Interface layers provide the hard-
ware and software interfaces necessary for retrieving the sensor data from sensors that are a
part of the Autonomy subsystem. The hardware associated with these layers are those that
23
Client Layer
Functional Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Autonomy Hardware Interface Layer
Autonomy Hardware Layer
Communication Link
Executive Layer
Planning Layer
Platform
Robot
Autonomy
Figure 4.5: Autonomy Architecture
are considered part of the removable autonomy module instead of hardware that is part of
the robotic platform (and, therefore, provided by the Backend.) The Autonomy Hardware
sensor data and Backend sensor data are ultimately used to make autonomous decisions.
The Functional Layer provides the functionality available to the upper, decision-
making layers. It has three components. The Platform component abstracts the Client
Layer from the remainder of the Autonomy subsystem. The Autonomy component provides
the basic functionality of the autonomy hardware (via API and controllers) and parallels
how the Functional Layer of the Backend subsystem provides the basic functionality of
24
the platform. Finally, the Robot component utilizes the functionality of the Platform and
Autonomy components to create new functionality for use by the Executive Layer.
The Planning and Executive layers work together to handle all the high-level decision-
making for the Autonomy subsystem. To do this, the Planning Layer determines what tasks
are needed to complete a mission and the Executive Layer must invoke the functionality in
the Functional Layer to carry out these tasks.
4.5 Architecture Paradigm
With the general architecture presented, it is now possible to relate RAMP to the
teleoperated and autonomous paradigms described in Chapter 2. When under teleoperated
control, the subsystems of RAMP interact as shown in Figure 4.6. Comparison with a basic
teleoperated architecture in Figure 2.2 shows that the Frontend subsystem acts as the local
subsystem, providing the operator an interface to control and examine the remote platform.
The Backend acts as the remote subsystem, providing the interface to the actuators and
sensors on the platform on the remote side of the communication link.
When operating autonomously, comparison of the RAMP architecture in Figure 4.7
and with the hybrid paradigm in Figure 2.5 shows that RAMP is structured as a hybrid
architecture. The Planning and Executive layers of the Autonomy subsystem act as the Plan
component of the system. The remaining layers of the Autonomy subsystem collaborate with
the Backend subsystem to provide the controllers and interfaces that represent the Sense and
Act components in the hybrid architecture.
25
Client Layer
Mapping Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Operator Hardware Interface Layer
Operator Hardware Layer
Human Operator
Communication Link
Functional Layer
Server Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Platform Hardware Interface Layer
Platform Hardware Layer
Functional Layer
Robotic Platform
Robot Distribution Layer
Backend Subsystem
Frontend Subsystem
Module Distribution Layer
Figure 4.6: Teleoperated Architecture
26
Autonomy Subsystem
Communication Link
Server Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Platform Hardware Interface Layer
Platform Hardware Layer
Functional Layer
Robotic Platform
Robot Distribution Layer
Client Layer
Functional Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Autonomy Hardware Interface Layer
Autonomy Hardware Layer
Executive Layer
Planning Layer
Backend Subsystem
Module Distribution Layer
Figure 4.7: Autonomy Architecture
27
4.6 Subsystem Communication
Communication with the Backend subsystem through the server requires an applica-
tion layer protocol understood by both the Backend server and the Autonomy and Frontend
clients. The application layer protocol is responsible for carrying two types of data between
the subsystems: requests for the Backend and responses from the Backend. This section
examines the necessary components for both types of messages.
4.6.1 Request
The first type of message is a request for the Backend. These messages include both
requests for the Backend to carry out an action and requests for new status information.
Four pieces of information are necessary to communicate a request:
1. Module;
2. Device;
3. Function;
4. Parameter.
Each field is derived from the Distribution and Functional layers of the Backend.
As a request is received and parsed by the Server Layer of the Backend, it is passed
to the Robot Distribution Layer. The Robot Distribution Layer must know whether the
request is intended for the robot as a integrated platform or whether it is destined for a
specific module. This information will be carried in the request’s Module field. When
a request is propagated to the Module Distribution Layer, the Backend must know what
component of the module’s Functional Layer is being queried. This is carried in the Device
field.
Once reaching the Functional Layer, the Backend must determine what type of request
is being made. The type of request is carried in the Function field. This field indicates
whether it is a request for data or a request for an action and, if so, what kind of action.
Finally, clients need to be able to append parameters to the request. The Parameter field
28
carries this information. With these four fields, the Functional Layer has enough information
to invoke the correct hardware and controllers to carry out a task.
4.6.2 Response
A response message is generated based on a request for data and follows the reverse
path of the request that spawned it. When the Backend receives a request for data, it
must first query the hardware or controllers via the Functional Layer to get the desired
information. The type of data and value of the data are stored in a Property and Value
field in the response message. To provide context on the Property, as the request rises back
up through the layers to be returned to the client by the server, the Distribution Layer also
appends the Device and Module fields just as they were originally received. This results in
a response message also with four fields:
1. Module;
2. Device;
3. Property;
4. Value.
The size and format of these fields is not limited by the architecture and is determined based
on implementation-specific requirements.
29
CHAPTER 5
CASE STUDY
This chapter presents an implementation of RAMP on the University of Alabama
MARTE platform as part of the 2013-2014 NASA Robotics Mining Competition as a case
study.
5.1 NASA Robotic Mining Competition
The 2014 NASA Robotic Mining Competition (RMC) is a competition “for university-
level students to design and build a mining robot that can traverse the simulated Martian
chaotic terrain, excavate Martian regolith and deposit the regolith into a Collector Bin
within 10 minutes” [31]. Teams “can use telerobotic or autonomous operation to excavate
the basaltic regolith simulant” and are awarded additional competition points for the more
autonomous capability they are able to demonstrate during a competition run.
The competition takes place in a walled 7.38 x 3.88 meter arena, as shown in Figure
5.1. The arena is divided into three regions: the starting, obstacle, and digging regions. The
starting region is further broken down into two starting boxes. Prior to each competition
run, a competition robot is placed in one of the two starting boxes facing one of four possible
cardinal directions. The starting box and direction are selected randomly prior to entrance
into the arena. The collection bin for depositing the excavated regolith is mounted centered
on the outside of the starting region’s 3.88 meter length wall. During a run, the robots are
required to excavate and deliver at least 10 kilograms of regolith simulant to qualify. The
rules state that all collected simulant must be excavated from the digging region of the arena,
the region on the side opposite the starting region. To reach the digging region, robots must
navigate and traverse the obstacle region, the center region of the arena. The obstacle region
30
is populated with three rocks and two craters, each up to 30 centimeters in diameter. The
placement of these obstacles is chosen by the competition judges prior to each round of the
competition.
Figure 5.1: RMC Arena Diagram [31]
Once the robot is placed within the arena, the systems are powered, and connection
is establish, operators may only interact with the robot remotely. During the competition
run, the operators are stationed in a control room isolated from the arena. Operators are
provided an Ethernet IEEE 802.3 switch that is wired to the arena where competitors are
expected to bring and connect a wireless access point. Communication with the robot in the
arena occurs by utilizing this access point. The competition places an additional constraint
on the wireless link between the access point and the robot; it must use channel 1 or 11 of
the IEEE 802.11 b/g protocol to allow judges to manage and minimize potential interference
between competing robots.
31
5.2 MARTE Platform
The University of Alabama’s entry for the 2014 NASA RMC was MARTE [32]. The
MARTE platform and RAMP computational architecture were designed and implemented
concurrently during the 2014 competition cycle. This section presents the MARTE robotic
platform upon which RAMP was realized.
As implied by its name, MARTE is a modular platform. A key design goal for this
platform was to provide a common frame and drive-train upon which an array of possible
payload modules, primarily excavation modules, can be mounted. The common platform is
called the Base module. During the development process, various excavation modules were
designed. One was ultimately chosen for implementation for this competition, the Bucket
Ladder Excavator (BLE) module. Figure 5.3 shows three designed excavation modules along
the top row, followed by the Base module in the center. The bottom image shows the
resulting MARTE platform when the top-center module, the BLE, is mounted atop the
Base module. This case study focuses on the RAMP implementation of the Base and BLE
modules.
Figure 5.2: MARTE (Base and BLE Modules)
32
Figure 5.3: MARTE Modularity [32]
33
5.2.1 Base Module
The Base module is the common module that defines the standard mechanical and
electrical interfaces through which all other potential modules attach. Mechanically, it pro-
vides a flat, rectangular, aluminum frame with four mounting holes for attaching a payload
module. Electrically, the Base houses and makes available an unregulated 17 to 21 volt
power supply for use by any attached modules. This rail is powered by two 5000 mAh 18.5
V LiPo batteries wired in parallel. This power system can be disconnected via a toggleable
push button to meet safety requirements defined by the competition rules.
The Base also provides a standard, four-wheel drive train. Each wheel is indepen-
dently controllable by separate channels on two dual-channel Sabertooth 2x60 motor con-
trollers wired to four 343 oz-in motors, each paired with 256:1 gearboxes. The wheel’s axles
are centered below the gearboxes and driven via a chain system to provide an extended 7.75
inch ground clearance. The aluminum wheels are each 12 inches in diameter with eight 1
inch grousers for added traction in loose terrain.
Figure 5.4: MARTE Base Module
34
5.2.2 Bucket Ladder Excavator Module
The BLE module provides the primary digging, collection, and depositing function-
ality for the platform during the competition. The BLE uses a bucket ladder mechanism
consisting of 24 steel buckets attached to a belt driven by two motors, each controllable
through the channels on a 2x60 Sabertooth motor controller. This mechanism is used to
break up and carry the simulant from the surface of the arena to the on-board aluminum
storage bin. The entire storage bin and bucket ladder mechanism pivots on a point at the
upper rear of the module and is actuated by a 500 lb Thompson ball-screw linear actuator
with built in potentiometer-based feedback. This allows the bucket ladder mechanism to be
lowered into the soil to excavate or to be lifted, raising the front of the storage bin to allow
the collected regolith to slide off the rear of the robot into the competition collection bin.
The actuator is also controllable through a 2x60 Sabertooth motor controller channel.
Figure 5.5: MARTE Bucket Ladder Excavator Module
35
5.3 RAMP Implementation
As previously described, RAMP consists of three subsystems: the Backend, Frontend,
and Autonomy. On MARTE, these three subsystems are separated into three separate com-
puting systems. The Backend subsystem is a computational system located on the MARTE
platform. Central processing for the Backend subsystem, and the hardware necessary to
operate the Base module, is located on the Base platform while the BLE, and any other
payload module, carries its own devices and hardware. The Frontend is implemented as a
separate, portable system that can be carried to test locations or the command room for
a competition run. The Autonomy subsystem, being a removable subsystem, is a separate
computing platform that can be mounted on the MARTE platform when autonomous con-
trol is desired. This section describes the implementation details of each of these subsystems
as part of RAMP.
5.3.1 Subsystem Communication
First, it is beneficial to examine the implementation of the inter-subsystem commu-
nication as it is heavily related to the rules set by the competition. Of particular importance
for this discussion is the requirement that the communication link between the remote op-
erators and the robot must be implemented using an IEEE 802.3 Ethernet link followed by
a wireless hop using IEEE 802.11 b/g, all using an Internet Protocol (IP) based network.
This led to the following network design for the three subsystems.
IP over 802.3
IP over 802.11g
Command Room
Frontend
Backend
Autonomy
Router Router IP over 802.3
Arena Robot Platform
Communication Link
Figure 5.6: Subsystem Communication
36
Two Linksys WRT54G routers act as the two wireless communication link end points.
Each is loaded with the Tomato third-party firmware [33] and is configured to establish a
wireless bridge [34] between the two routers. This allows the Frontend subsystem connected
to the local router to address any systems connected to the remote router, including the
Backend and Autonomy (if attached) subsystems, as though they are on the same IP subnet.
IP networks commonly use the Transport Control Protocol (TCP) or User Datagram
Protocol (UDP) to assist in transportation of application data between programs running
on remote systems. In this implementation, TCP is used for communication between the
Backend server and the Frontend and Autonomy clients because it provides a connection-
based and reliable communication stream.
Communication of request and response data between the subsystems requires an
application protocol understood by both the source and destination of the message. A
custom application layer protocol, named the MARTE Control Protocol (MCP), and based
off the protocol described in Chapter 4, was implemented for this purpose. The protocol
was defined to carry all data in ASCII to ease the development and debugging process. The
format of a request message is shown in Figures 5.7 and 5.8 and the response message format
in Figures 5.9 and 5.10.
The MCP allows multiple requests to be transmitted within a single message sent
from a client to the Backend and, similarly, multiple responses to be returned within a single
message. The supported values for each of these fields is determined by the functionality
provided by the Backend and will be examined in detail in the following section. Finally,
Figures 5.11 and 5.12 summarize the flow of requests and responses between the subsystems
during both teleoperation and autonomous operation, respectively.
37
Module Device Function Param Param: . =( , , )...
MCP Request
MCP Request Message
Request Request ... \n
Figure 5.7: MARTE Control Protocol Request Message
message = { request }, "\n" ;
request = module, ":", device, ".", function, "=(", params, ")" ;
module = modulechar, { modulechar } ;
device = devicechar, { devicechar } ;
function = functionchar, { functionchar } ;
params = param, { ",", params } ;
param = paramchar, { paramchar } ;
modulechar = ? all characters except "\n" and ":" ?
devicechar = ? all characters except "\n" and "." ?
functionchar = ? all characters except "\n" and "=" ?
paramchar = ? all characters except "\n" and ")" ?
Figure 5.8: Request Message Format
38
Module Device Property Value Value: . =( , , )...
MCP Response
MCP Response Message
Response Response ... \n
Figure 5.9: MARTE Control Protocol Response Message
message = { response }, "\n" ;
response = module, ":", device, ".", property, "=(", values, ")" ;
module = modulechar, { modulechar } ;
device = devicechar, { devicechar } ;
property = propertychar, { propertychar } ;
values = value, { ",", values } ;
value = valuechar, { valuechar } ;
modulechar = ? all characters except "\n" and ":" ?
devicechar = ? all characters except "\n" and "." ?
propertychar = ? all characters except "\n" and "=" ?
valuechar = ? all characters except "\n" and ")" ?
Figure 5.10: Response Message Format
39
Rem
ote
Router
Operator
Platform
Local
Router
Frontend
Request
Request
Request
Response
Response
Response
Backend
Response
Response
Response
Request
Request
Request
802.3
IP TCP
MCP
Response
Message
802.3
IP TCP
MCP
Response
Message
802.11g
IP TCP
MCP
Response
Message
802.3
IP TCP
MCP
Request
Message
802.3
IP TCP
MCP
Request
Message
802.11g
IP TCP
MCP
Request
Message
Figure 5.11: MARTE Teleoperation Inter-Subsystem Communication
40
A
uto
nom
y
Rem
ote
Rou
ter
Plat
form
Req
ues
t
Req
ues
t
Req
ues
t
Res
pon
se
Res
pon
se
Res
pon
se
Bac
kend
Res
pon
se
Res
pon
se
Res
pon
se
Req
ues
t
Req
ues
t
Req
ues
t
802.3
IP TCP
MC
PRes
pon
seM
essa
ge
802.3
IP TCP
MC
PRes
pon
seM
essa
ge
802.3
IP TCP
MC
PReq
ues
tM
essa
ge
802.3
IP TCP
MC
PReq
ues
tM
essa
ge
Figure 5.12: MARTE Autonomy Inter-Subsystem Communication
41
5.3.2 Backend
This section begins the subsystem discussion with the Backend implementation for
the MARTE platform. As described in Chapter 4, the RAMP Backend consists of eight
layers (Figure 4.3.) These eight layers are organized on the MARTE platform as shown in
Figure 5.13.
Module Independent
Base Module Bucket Ladder Excavator Module
Robot Distribution Layer
Server Layer
Communication Hardware Interface Layer
Communication Hardware Layer
Functional Layer
Communication Link
Module Distribution LayerModule Distribution Layer
Functional Layer
Platform Hardware Interface Layer Platform Hardware Interface Layer
Platform Hardware Layer Platform Hardware Layer
Base Module Platform Bucket Ladder Excavator Platform
Figure 5.13: MARTE Backend Layers
42
The Backend implementation is based around a module-independent, single board
computer (SBC) as opposed to a distributed approach where each module would have sepa-
rate processors. The SBC chosen for the Backend is the Phidgets PhidgetSBC2 [35], shown
if Figure 5.14. It is built around the ARM based Samsung S3C2440 400 MHz processor
and has 64 MB of SDRAM. For external interfaces, it has one 10/100BASE-T RJ-45 port
for Ethernet support, six USB 1.1 ports, and a built in Phidgets PhidgetInterfaceKit 8/8/8.
The PhidgetInterfaceKit 8/8/8 provides eight digital input ports, eight digital outputs, and
eight analog to digital input channels.
Figure 5.14: Phidgets PhidgetSBC2 [35]
The first layer of the Backend is the Communication Hardware Layer. It must pro-
vide the Backend the capability to communicate with either the Frontend or the Autonomy
subsystem. As previously described in Section 5.3.1, the wireless communication link be-
tween the Frontend and Backend is handled by two Linksys WRT54G routers [36] (Figure
5.15) using 802.11g, one for mounting on the platform, and one for placement in the envi-
ronment around the competition arena. The on-board router is the first component of the
Backend’s Communication Hardware Layer; it is an off-the-shelf device that can manage
transmission and reception of data across the communication link. To connect the SBC to
the communication link, the SBC must interface to the router. The WRT54G provides five
43
10/100BASE-T RJ-45 Ethernet ports, one of which is utilized by the SBC for this purpose
through a Category 5e Ethernet cable connected to its own RJ-45 port. The PhidgetSBC2
contains the necessary built-in hardware components to make the signals through the Eth-
ernet port available to the on-board CPU. The Communication Hardware Layer for the
Backend is shown in Figure 5.16.
Figure 5.15: Linksys WRT54G [36]
For the SBC to interface to the communication hardware, the Communication Hard-
ware Interface Layer is necessary. In this case, the PhidgetSBC2 comes pre-installed with
the Debian GNU/Linux distribution. This operating system provides the necessary device
drivers and libraries to interface with the Ethernet controller on-board such that it can read
and create network traffic using the standardized POSIX sockets API [37].
Next, the Server Layer interfaces with the POSIX sockets API. It interprets the raw
data received as MCP request messages and, later, serializes MCP responses to be returned
to the client. The sockets library handles part of this process by implementing the IP and
TCP protocols. For example, it handles all the necessary low-level functionality needed by
the operating system to recognize that incoming data is intended for the SBC by examining
the IP header’s IP address field. The OS then uses the port number in the TCP header to
direct the received data to the program that executes the Backend server.
The key component of the Server Layer is a single-connection TCP/IP server written
in C. It manages instantiation, management, and interfacing with a bound TCP/IP POSIX
socket through which clients can attempt to establish a connection for communication with
44
Linksys WRT54G
Phidgets PhidgetSBC2 EthernetController
Communication Link
TCP/IP over 802.3
TCP/IP over 802.11g
CPU
Routing
Figure 5.16: MARTE Communication Hardware Layer
the Backend. To successfully communicate with a client, the TCP server must understand
the application layer protocol. While the OS provides implementations for IP and TCP, it
does not understand the custom-designed MCP. The MCP format is used in two ways by
the Server Layer. First, the server makes use of the newline character that indicates the tail
of a request message. This is important because IP-based messages can be fragmented into
separate packets in limited bandwidth situations. Therefore, the server must accumulate
fragmented packets until a full request message is received by the Backend. The end of a
complete message is indicated by receiving the MCP trailing newline. Second, the server
implements a custom parser to convert raw network data into a C structure representing
requests to be used by the two Distribution layers. Similarly, a serializer converts a response
45
structure back into the raw data to be transmitted to the client. The Server Layer is
summarized by Figure 5.17.
POSIX Sockets
Communication Hardware Interface Layer
TCP Server
Fragmented Packet Data
MCP Parser MCP Serializer
Request Message Data Response Message Data
Robot Distribution Layer
List of Requests List of Responses
Network Data
Figure 5.17: MARTE Server Layer
The list of MCP requests received by the Server Layer is next used by the Robot
Distribution Layer. Each request in the list is examined as a separate entity and is handled
independently of other requests that arrived as part of the same message. The primary MCP
field of importance to the Robot Distribution Layer is the Module field. The Module field
tells the algorithm to handle the request in one of two ways. First, the Module field can
indicate that the request is meant to act on the robot as a full, integrated platform. The
alternative is that the Module field can indicate the request is destined for a specific module.
The former case is indicated by a value of robot in the Module field. When the
field matches this value, the request is passed to a function for further interpretation and
handling. This function analyzes the remaining fields of the request. Three such robot
requests are currently implemented on the MARTE system and the acceptable values for
the other fields are shown in the first three rows of Table 5.1. Two of these requests, the
robot.modules() and watchdog.timeout(int), make requests on the Robot Distribution
46
Layer itself without directly interacting with a module. The first queries for a response
containing a list of the modules that are attached to the robot platform. This response is
shown in Table 5.2. A client can use this response to determine which modules are currently
available and, therefore, what functionality the system is capable of. The second request
is related to a watchdog timer. This watchdog timer is a constantly decrementing timer
managed by the Robot Distribution Layer. When the timer expires, a stop request is
distributed to all attached modules, ordering the platform to stop all movement. This is a
safety feature for development and demonstration purposes to handle situations in which a
client loses connection to the Backend. The timer is reset every time a new list of requests
is received from the Server Layer. Therefore, as long as the client keeps a constant flow of
requests or a heartbeat message (a request message containing no requests, just the trailing
newline defined by the MCP), the timer will not expire and the platform will continue
to operate normally. The final robot request is a stop command. This demonstrates an
operation for the system as a whole: to stop all current movement. From a client’s point of
view, this request is module-independent. When the Robot Distribution Layer detects this
request, it looks at which modules are currently attached and commands each to stop. In
the MARTE implementation, all modules are standardized to require that it understand a
stop command.
When the Module field is not robot, it is considered to be the name of a specific
module. In this case, the Robot Distribution Layer does not care what values are in the
remaining fields. Instead, it must determine how to forward the request to the module
specified in the field. To accomplish this, the Robot Distribution Layer manages a list
of modules using a standardized interface. In the MARTE implementation, each module
capable of attaching to the system must provide functions to initialize, shutdown, and receive
a request destined for that module’s Module Distribution Layer. This collection of modules
is first used to determine if the value in the Module field is recognized by the system.
If the Robot Distribution Layer does not recognized the module name, an error response is
47
returned. If it is recognized, the layer must next determine if the module is currently attached
to the platform. The current implementation of MARTE does not support hot swapping of
modules during operation. Instead, the initialization interface provided by each module is
used during boot. If the module can be initialized, it is considered attached and available for
requests. When attached, the request is passed to the module’s Module Distribution Layer.
Finally, once all requests in the request message are handled, all generated responses
are aggregated together into a single list of responses to be returned to the Server Layer for
serialization and transmission.
Module Device Function Parameters Description
robot
robot modules null Respond, listing all attached modulesrobot stop null Request all modules to stop movingwatchdog timeout int Set watchdog timeout value (seconds)
base * * * Forward request to the Base moduleble * * * Forward request to the BLE module
Table 5.1: MARTE Robot Distribution Layer Requests
Module Device Property Values Description
robot robot modules string, string, ... List of names of attached modules
Table 5.2: MARTE Robot Distribution Layer Module List Response
The remaining layers of the Backend subsystem have module dependent implemen-
tations. For the Base and BLE modules, the software for these layers is implemented as
part of the same program executing the module-independent layers previously described.
This is not a requirement for the MARTE system. Alternatively, a module’s software im-
plementation could execute within a separate program or on an entirely separate computing
platform. The only requirement is that the module provide the standard interface to the
Robot Distribution Layer. This interface can mediate the transfer of data between the the
Robot and Module Distribution layers.
The remaining hardware components of the two modules, such as motor controllers
and sensors, are mounted on the modules themselves. To be made accessible to the software
48
executing on the SBC, these components must interface to the SBC. This is done through
the various I/O and USB ports available on the SBC and could also potentially utilize the
on-board network through the four remaining RJ-45 Ethernet ports on the WRT54G router.
The interconnections between the hardware components and the SBC are shown in Figure
5.18.
Module Independent
Base Module Bucket Ladder Excavator Module
Phidgets PhidgetSBC2
TCP/IP over 802.3
Linksys WRT54G
DO x8 DI x8 ADC x8 USB x6
Push Button
Push Button
Motor
Motor
Motor
Motor
MotorController
MotorController
LED x4
Power RailVoltageMonitor
Motor
Motor
MotorController
ActuatorMotor
MotorController
USB to Serial USB to Serial
ActuatorFeedback
InterfaceKit
Load CellBridge
Figure 5.18: MARTE Hardware Connections
49
5.3.2.1 Base
When a request is passed from the Robot Distribution Layer to the Base’s Module
Distribution Layer, all fields are analyzed and matched against the functionality the Base
provides. The Device and Function fields of the request are checked against the known
functionality and, if recognized, the relevant functionality in the Functional Layer is invoked
using the values carried in the Parameters field. The available requests understood by the
Base module are listed in Table 5.3.
These requests provide a range of control abstraction. High-level functionality in-
cludes the drive and stop commands which affect the Base as an integrated module. Al-
ternatively, low-level requests include the vel commands for driving each of the four wheels
independent of the others, or the user_led request that can turn an LED on or off. The get
request allows a client to request the status of all aspects of the Base. When this request
is received, a collection of responses, shown in Table 5.4, is returned to be displayed to the
teleoperator or for use in decision-making by the Autonomy subsystem.
Module Device Function Parameters Description
base
base get null Respond with full statusbase drive int, float Drive at a velocity in a given directionbase stop null Stop all movementlf_wheel vel int Drive the left front wheel at a velocitylb_wheel vel int Drive the left back wheel at a velocityrf_wheel vel int Drive the right front wheel at a velocityrb_wheel vel int Drive the right back wheel at a velocityuser_led on int Set an LED on or off
Table 5.3: MARTE Base Module Distribution Layer Requests
The Functional Layer contains the algorithms and controllers for carrying out the re-
quests defined by the Module Distribution Layer. It is hierarchical in design, with high-level
functions utilizing low-level ones to improve code reuse and maintainability. Figures 5.19
and 5.20 show how a base.drive(int, float) and rf_wheel.vel(int) command propagate
through the relevant components in the Functional Layer. The “Base Drive” function, for
50
Module Device Property Values Description
base
lf_wheel vel int The current velocity of the left front wheellb_wheel vel int The current velocity of the left back wheelrf_wheel vel int The current velocity of the right front wheelrb_wheel vel int The current velocity of the right back wheell_button press int Is the left docking button depressedr_button press int Is the right docking button depressedbattery volt float The voltage of the power railuser_led on int Is the LED on or off
Table 5.4: MARTE Base Module Distribution Layer Get Responses
example, is an implementation of a simple trigonometric-based algorithm that converts veloc-
ity and direction-based commands into individual wheel velocity commands. Each “Wheel”
abstracts a “Motor” interface. These “Motor” components provide a configurable interface
that stores and utilizes, for example, the polarity of a motor. This means the “Wheel” and
high-level components can request a specific direction of rotation regardless of how the motor
is wired to the motor controller.
LB Wheel
Module Distribution Layer
Base Drive
LF Wheel RF Wheel
RB Wheel
Platform Hardware Interface Layer
LB Motor
LF Motor RF Motor
RB Motor
Figure 5.19: MARTE Base Functional Layer: Base Drive
A more complex example on the Base module is the voltage monitoring system shown
in Figure 5.21. These functions collaborate to both provide the current system voltage to a
client and to display the voltage level on a row of LEDs. At the lowest level is the “Voltage”
51
LB Wheel
Module Distribution Layer
Base Drive
LF Wheel RF Wheel
RB Wheel
Platform Hardware Interface Layer
LB Motor
LF Motor RF Motor
RB Motor
Figure 5.20: MARTE Base Functional Layer: Wheel Drive
component, a wrapper around the underlying ADC interface in the Platform Hardware
Interface Layer. It converts the value on the ADC channel to the corresponding voltage of
the power rail. The “Voltage” component is utilized by a “System Voltage” component. This
is a threaded object that continuously accesses the instantaneous “Voltage” and averages the
current value with a collection of previous values to provide a low pass filter. This helps
hide high frequency changes on the power rail due to load spikes. The “System Voltage”
component is queried by the Module Distribution Layer when the client makes a get()
request.
Components in the Functional Layer do not always map to a specific request. The
Backend provides three LEDs for indicating the battery voltage. This is handled by the
“Voltage Display” component in Figure 5.21. This component is also threaded, constantly
requesting an updated voltage value from the “System Voltage” component. This voltage
is used to control the three LEDs. Each LED also executes as separate threads, providing
the functionality to request the LED to blink at a desire rate. Overall, this system turns on
all LEDs when the battery is near full charge, then, one-by-one, blinks and extinguishes the
LEDs as the voltage drops to indicate the battery is depleting.
52
Module Distribution Layer
Platform Hardware Interface Layer
High LED
Middle LED Low LED
Voltage
System VoltageVoltage Display
Figure 5.21: MARTE Base Functional Layer: Voltage System
The Platform Hardware Interface Layer provides the interfaces necessary to facilitate
communication between the PhidgetSBC2’s CPU and the hardware devices that make up
the Base module’s Platform Hardware Layer. Figure 5.18 already briefly touched on the
devices and peripherals that make up the Base’s Platform Hardware Layers.
As mentioned at the beginning of the chapter, the Base module consists of a four-
wheeled drive-train and provides a global power rail for any other attached modules, such
as the BLE. The four wheels are driven by four separate motors, each attached to separate
channels on two dual-channel Sabertooth 2x60 motor controllers [38]. These motor con-
trollers provide multiple different interfaces. The Base is configured to use the Sabertooth’s
TTL level RS-232 packetized serial interface for addressing and communicating with multiple
boards on a common bus. The PhidgetSBC2 does not contain a serial interface, therefore
the Base’s Platform Hardware Layer also contains an off-the-shelf USB-to-serial converter.
To monitor the voltage on the power rail, a Phidgets Voltage Sensor [39] converts
the voltage of the power rail down to an analog signal usable by the SBC’s analog to digital
channel. The Base also contains two push buttons mounted on one side of the platform to
provide the ability to “feel” the wall of the arena, each of which is connected to separate
53
Figure 5.22: Sabertooth 2X60 Motor Controller [38]
digital input channels on the SBC. Finally, the Base has four LEDs interfaced with the
software system through the digital output pins. Three work as the previously discussed
voltage display. The fourth is a general purpose LED settable by the user_led request.
The Platform Hardware Interface Layer interfaces the Functional Layer with this
hardware. The digital and analog channels on the SBC are accessed through the official
Phidgets21 C library [40]. Interfacing with the motor controllers uses both a custom li-
brary for communicating using the Sabertooth’s packetized serial message format and the
GNU/Linux provided termios interface used to communicate with a serial device. In this
case, the termios library is directed to utilize the FTDI driver that can communicate with
the USB-to-serial device as if it is directly interfacing with the serial line.
54
5.3.2.2 BLE
While the BLE module differs completely from the Base operationally, the implemen-
tation of the four module dependent layers bear many similarities. The Module Distribution
Layer for the BLE is identical in structure to the Base, but differs in the request fields it
accepts and responses it returns (Figures 5.5 and 5.6).
Module Device Function Parameters Description
ble
ble get null Respond with full statusble stop null Stop all movementlift vel int Extend the lifting arm at a velocitylift extend null Extend the lifting arm at full speedlift retract null Retract the lifting arm at full speedlift pos float Set the lifting arm to a positionchain vel int Drive the bucket ladder chain at a velocity
Table 5.5: MARTE BLE Module Distribution Layer Requests
Module Device Property Values Description
ble
lift vel int The current velocity of the lifting armlift pos float The current position of the lifting armchain vel int The current velocity of the bucket ladder chainload kg float The weight in the onboard collection bin
Table 5.6: MARTE BLE Module Distribution Layer Get Responses
The remaining three BLE-dependent layers are shown as a whole in Figure 5.23 start-
ing with the Module Distribution Layer at the top and ending with the Platform Hardware
Layer at the bottom.
The BLE module operates through four peripherals. Two motors work together
through a Sabertooth 2x60 motor controller to operate the bucket ladder’s belt mechanism.
This motor controller is configured identically to the Base’s motor controllers, but exists on
a separate USB-to-serial provided bus. This USB-to-serial device is made available to the
SBC when the BLE is attached. A linear actuator with built-in potentiometer feedback is
used to raise and lower the storage and digging mechanism. It is driven by one channel on
another Sabertooth motor controller. The potentiometer feedback is connected to the ADC
55
channel of a PhidgetInterfaceKit, the same model of device that is built into the SBC. While
ADC channels on the SBC are available, additional physical constraints were placed on non-
Base modules that they must interface to the SBC electronically only through USB or the
Linksys router. Finally, a PhidgetBridge for reading Wheatstone bridge circuits is used with
a load cell mounted on the linear actuators mounting point to provide an estimated on-board
collected load. The PhidgetInterfaceKit has a built-in USB hub that is used to route the
PhidgetBridge, PhidgetInterfaceKit, and USB-to-serial data to and from the SBC when the
BLE is attached. The Platform Hardware Interface Layer uses the same Sabertooth/termios
API and Phidgets21 library used on the Base to interface to this hardware.
Finally, the Functional Layer provides the basic functionality for the BLE. It is imple-
mented in the same fashion as the Base’s Functional Layer but with the specific algorithms
necessary to handle the requests specified in Table 5.5. Most interesting is the group of com-
ponents handling the linear actuator. The “Thompson Actuator” component is threaded to
provide the capability to request a specific position to set the actuator. It implements a basic
on-off controller using the feedback from the potentiometer. A more complex controller is
unnecessary due to manufacturer specifications that the actuator only be driven by a DC
signal, not a rapidly changing voltage such as one provided by a PWM-like signal.
56
Module Distribution Layer
Feedback Linear Actuator
Motor
ThompsonActuator
Load Cell Motor Motor
Bucket Ladder
Sabertooth BusInterface
termios API
FTDI Driver
Phidgets 21Library
MC ChannelInterface
SabertoothInterface
ADC ChannelInterface
Bridge ChannelInterface
SabertoothInterface
MC ChannelInterface
MC ChannelInterface
InterfaceKitInterface
BridgeInterface
PhidgetInterfaceKitPhidgetBridge
USB Controller
USB-to-Serial
SabertoothSabertooth
MotorMotorActuator MotorActuator PotentiometerLoad Cell
Functional Layer
Platform Hardware Interface Layer
Platform Hardware Layer
Figure 5.23: MARTE BLE Functional/Hardware Layers
57
5.3.3 Frontend
The Frontend subsystem is designed to facilitate communication between the human
operators and the Backend on the remote MARTE platform. As a whole, the Frontend is
designed to be usable on a wide variety of general computing systems. This section covers
the implementation of the seven layers of the Frontend subsystem for use with MARTE.
To manage the local side of the communication link with the Backend subsystem, the
Frontend Communication Hardware Layer uses an identical model Linksys WRT54G router
as used on the Backend Communication Hardware Layer. As previously described, these two
routers are configured through the Tomato firmware to operate as a wireless bridge between
the remote IP subnet and local IP subnet. Communication between the operator computer
executing the Frontend software and the local router is achieved through one of the five
RJ-45 Ethernet ports on the router. Generally this is connected to a similar RJ-45 port on
a network interface card, but the specific interface is left to the administrator.
The Frontend software developed for the MARTE is a C# application heavily utilizing
the Microsoft .NET Framework. Interfacing this software with the Communication Hardware
Layer occurs through the System.Net.Sockets API in the .NET Framework class library.
This API utilizes the operating system networking drivers installed. The installation of
these drivers will likely be provided by the operating system or the networking interface
card manufacturer, but is ultimately up to the computer administrator to ensure the .NET
Framework installation can successfully communicate with the IP network.
At the lowest level, the Client Layer is implemented as an instance of the System.Net.
Sockets.TcpClient class in the .NET Framework. This class handles the interaction with
the System.Net.Sockets API to successfully communicate using the TCP/IP protocols as
defined at the beginning of the chapter. Much like the Backend’s Server Layer, the Frontend’s
Client Layer contains a custom C# implementation of the MCP application protocol so
58
that it can successfully serialize and send request messages and receive and parse response
messages.
The Functional Layer provides the functionality of the Frontend and determines what
the operator can do with the platform. The commands available to the operator are depen-
dent on the modules attached to the platform. The modules attached are requested by
sending a robot:robot.modules=() request to the Backend through the Client Layer. If
the module is returned as attached, the Frontend creates a class instance for that particular
module, containing all the functionality that module provides. The Functional Layer also
provides a thread for regularly querying the status of all attached modules using the relevant
get=() requests. The results are stored as status values within the individual module classes
for use by the Mapping Layer. This regular status request also serves as the heartbeat for
keeping the safety watchdog timer on the Backend from timing out and halting the platform.
Figure 5.24 shows how the status update timer invokes the get request for the active
modules (in this case both the Base and BLE are shown as attached). These, in turn, invoke
requests through the Client Layer. The returned responses are then used by the specific
module class to populate the current known status of that module. Figure 5.25 shows the
Mapping Layer using the known status to be mapped to the display while also allowing the
Mapping Layer to invoke the other supported requests provided by each module.
Before examining the Mapping Layer, it is beneficial to look at the Operator Hardware
layers. To interact with the operator, the Frontend needs both input devices to receive user
input and output devices to provide feedback. User input is detected using three potential
peripherals. The first two are standard devices available on most personal computers: a
keyboard and mouse/touchpad. The third, a Microsoft Xbox 360 controller (Figure 5.26),
provides two analog joysticks, two pressure-sensitive triggers, a directional pad, and a variety
of buttons for a more familiar driving interface.
Connection of these three peripherals to the computer varies from system to system.
For desktop computers, the keyboard and mouse general connect via a PS/2 or USB. The
59
StatusUpdateTimer
Mapping Layer
Commands Get Get
Client Layer
CommandsStatus Status
Attached Modules
Base BLE
...
Figure 5.24: MARTE Frontend Functional Layer: Status Update
StatusUpdateTimer
Mapping Layer
Commands Get Get
Client Layer
CommandsStatus Status
Attached Modules
Base BLE
...
Figure 5.25: MARTE Frontend Functional Layer: From Mapping
Xbox 360 controller generally uses a USB connection. Display of data to the operator is
generally handled through an external or built-in monitor on the computer driven by a
graphics card.
The low-level interfacing of this hardware to the operating system is also left up to
the owner and administrator of the computer executing the Frontend software. Mouse and
keyboard drivers are generally provided by the OS and graphics drivers are provided by
the manufacturer or OS. The rest of the Frontend interfaces with these peripherals through
60
Figure 5.26: Microsoft Xbox 360 Controller [41]
the System.Windows.Forms .NET library. Communication with the Xbox 360 controller is
handled by the Microsoft XNA Framework for the Microsoft .NET Framework.
The Mapping Layer makes heavy use of the System.Windows.Forms library for han-
dling how the status of the system is displayed and for using and interpreting keyboard
and mouse input from the operator. The display of the Frontend is shown as a Windows
Form GUI. The GUI consists of a main window, or form, that serves as the foundation
for the operator’s display. It contains information that is always displayed, independent of
the modules attached. For example, it has a tree structure containing the list of attached
modules and the devices within each module. It also contains a button for displaying a con-
nection debugging popup window that determines whether Xbox controllers are attached,
if the routers are reachable, and if connection to the Backend is established. Each module
also contains a form specific for displaying the status of that module. Each module form
is selectable through the active module/device tree structure previously mentioned on the
general window. These module specific forms determine how the status information queried
from the Functional Layer is displayed.
The robot can be controlled by the operator using either the Xbox 360 controller or
using mouse and keyboard operations within the GUI. A case of the latter is the Base module
61
form which provides text boxes and buttons for manually setting the velocity of each wheel.
The Mapping Layer maps those inputs to the Functional Layer which will eventually result
in a base:XX_wheel.vel=(int) request. These types of inputs are useful for the operator
to debug or test specific components of the platform through the Frontend.
The primary means of operating the robot is the Xbox 360 controller. The Mapping
Layer contains a method for each module that maps the joystick and button presses to the
specific methods in the Functional Layer. For example, the Base module class maps one
of the joysticks to the function for the base:base.drive=(int, float) command. The BLE
maps a trigger to the velocity of the bucket ladder and a button to set the linear actuator
to a pre-set raised position used while traversing the arena.
5.3.4 Autonomy
The Autonomy subsystem is designed to replace the teleoperator during autonomous
operation. The basic strategy of the Autonomy subsystem’s operation is divided into several
distinct states. First, the system needs to determine its starting position and orientation
(pose) within the starting region since the robot could begin in one of two general locations
facing one of four general directions, further compounded by smaller variations in the exact
placement due to the manual placement of the robot in the arena. Once the robot has
determined its initial pose, it needs to determine how to reach the digging region. To do
this, it travels to a central location in front of the obstacle region and scans the arena for
rocks and craters. These obstacles are marked on a map and a path is planned through
the obstacle region to the digging region. The robot then traverses the path and begins
excavation in the digging region. Once excavation has completed, it plans and follows a new
path back to the center of the starting region. To complete the cycle, the robot centers itself
with the bin, docks, and deposits the collected regolith. Finally, the robot decouples with
the bin, re-plans a path to a new location in the digging region, and repeats the general
excavation and delivery process until time expires.
62
Various sensors and hardware components make up the Autonomy subsystem hard-
ware to implement the capabilities necessary to follow this general approach. To scan the
environment for obstacles and known features, a Hokuyo UTM-30LX-EW (Figure 5.27) LI-
DAR sensor is used. It can collect 1,080 range measurements across a 270◦ horizontal sweep
up to 30 meters within a single scan. It is accessible through a 100BASE Ethernet inter-
face. The LIDAR is mounted atop a SPT200 pan and tilt platform actuated by two Hitec
HS-5645MG digital servos (Figures 5.28 and 5.29). A Phidgets PhidgetSpatial sensor board
is used to provide a 3-axis gyroscope and 3-axis accelerometer (Figure 5.30).
Figure 5.27: Hokuyo UTM-30LX-EW [42]
Figure 5.28: SPT200 Pan & Tilt System [43]
All sensors involved in the implementation of the autonomy strategy are mounted
63
Figure 5.29: Hitec HS-5645MG Servo [44]
Figure 5.30: Phidgets PhidgetSpatial 3/3/3 Sensor [45]
on-board the robot platform instead of mounting sensors or beacons in the environment.
The Autonomy subsystem in RAMP is completely removable, meaning these sensors are not
necessary for the platform to operate and can be removed during teleoperated control. The
software for the Autonomy subsystem executes on a separate computing system than that
of the Backend’s PhidgetSBC so that it can be removed with the sensors during planned
teleoperation-only operation. A VIA EPIA-P900 Pico-ITX form factor SBC (Figure 5.31)
acts as the computing platform for the Autonomy subsystem. It contains a 1.0 GHz VIA
Eden X2 dual core x86 compatible 64-bit processor and is installed with 4 GB of RAM and
64
a Solid-state harddrive. An extension board provides two USB ports and an RJ-45 Ethernet
port.
Figure 5.31: VIA EPIA-P900 [46]
To query the accelerometer and gyroscope data, the PhidgetSpatial board is connected
to the VIA SBC using USB. To control the SPT200 pan and tilt platform actuated by the two
Hitec servos and carrying the Hokuyo LIDAR, an eight channel PhidgetAdvancedServo servo
controller board [47] is used and interfaced to the VIA SBC also using USB. Communication
between the VIA EPIA SBC and Hokuyo LIDAR is facilitated by two ports on a simple
eight port IEEE 802.3 Ethernet switch, connected to the LIDAR and SBC’s RJ-45 ports.
The Autonomy subsystem also has a Communication Hardware Layer for controlling
and querying the Backend to ultimately drive the platform. This is done by connecting
one port of the Autonomy subsystem Ethernet switch to an open port on the remote/on-
board Linksys WRT54G router. An overview of the hardware connections for the Autonomy
subsystem is shown in Figure 5.32.
65
Backend
TCP/IP over 802.3
PhidgetsPhidgetSBC2
TCP/IP over 802.3
Linksys WRT54G
Servo
Servo
ServoController
LIDAR
IMU
EthernetSwitch
VIA EPIA-P900
USB x7
Pan/Tilt
Autonomy
TCP/IP over 802.3
Figure 5.32: MARTE Autonomy Hardware
The VIA EPIA SBC for the Autonomy subsystem is loaded with version 12.04 of the
Ubuntu GNU/Linux operating system. Interfacing the software with the hardware in the
Autonomy Hardware Interface and Communication Hardware Interface layers is comparable
to the Hardware Interface Layer of the Backend subsystem. Communication through USB
and Ethernet are handled at the low-level by the operating system kernel and provided
drivers. Interfacing to the PhidgetSpatial IMU and PhidgetAdvancedServo controller are
provided by the same Phidget21 API. Network traffic is transmitted and received through
the POSIX socket API. Communication with the Hokuyo LIDAR is done using the Scanning
Range Sensor Communication Interface Protocol (SCIP) with TCP/IP over Ethernet [48].
The URG Helper C library [49] is used as the implementation of this protocol.
Communication with the Backend is handled by the Client Layer, much in the same
66
way as the Frontend subsystem’s Client Layer. But, whereas the Frontend uses the .NET
System.Net.Sockets API, the Autonomy system was developed in C++ and uses the
POSIX sockets API. A C++ implementation of MCP is implemented for use by the Client
Layer to communicate with the Backend.
The Functional Layer of the Autonomy subsystem provides all the basic functionality
available to the higher, decision-making layers of the subsystem. Part of this functionality
relates directly to communication with the Backend, to control and access the status of
the platform. The components for these related functions are simply layers of abstraction
wrapped around direct use of the Client Layer, hiding the distributed nature of such op-
erations from other components of the Functional Layer and the Executive Layer. These
include operations such as telling the platform to drive, operating the digging mechanism,
and reading the weight of the load. The availability of some of these functions is dependent
on the modules attached. For example, the BLE module provides a raise and lower function
for actuating the digging mechanism and bucket. The “Excavate” Autonomy functionality
makes use of this ability along with the ability to drive and measure weight. If a different
excavation module were implemented and attached, the “Excavate” functionality would still
be available to higher functions and the Executive Layer would need to implement module-
specific low-level functionality in the Functional layer that would likely differ from the BLE’s
raise and lower mechanism.
The Functional Layer also has functionality directly related to the Autonomy Hard-
ware layers. An overview is shown in Figure 5.33. At the lowest level are components for
basic functionality of the sensors and actuators. The URG Helper library and a collection of
custom C++ classes provide the functionality for collecting a 2D scan from the Hokuyo LI-
DAR. A custom component was also written for the servos and pan/tilt platform to request
specific degrees of pan and tilt. A threaded attitude and heading reference system (AHRS)
component was written to provide an overall pitch and roll of the platform versus gravity
67
using periodic updates from the accelerometer and gyroscopes. The AHRS also uses this
data to provide a overall yaw of the platform from a reference orientation.
3D ScannerLocalizer
AHRS Pan/Tilt
LIDAR
Gimbal
Pan ServoTilt ServoGyroscopesAccelerometers
URG Helper Phidget21
Functional Layer
Autonomy Hardware Interface Layer
Figure 5.33: MARTE Autonomy Functional Layer: Autonomy Hardware
These functions are then used to provide more advanced functionality. A gimbal
component utilizes the pan/tilt platform and the AHRS to make the pan/tilt keep the
LIDAR at a constant orientation versus gravity, even as the platform moves across the
uneven terrain. A localizer component utilizes the LIDAR, AHRS and gimbal, along with the
knowledge of the arena walls as features, to keep up with the global location and orientation
of the platform. The localizer uses the gimbal to keep the LIDAR level with the horizon
and, thus, with the walls of the arena. The localizer then uses the LIDAR’s ability to collect
2D scan data to get distance measurements to the walls. Straight lines are extracted from
the distance measurements and are matched to the map of the arena to find potential poses
for the platform. Because the arena is symmetrical, there will always be at least two, and
up to four, potential poses from the scan alone. During initialization of the system during a
68
competition run, the Autonomy subsystem knows that the platform is in the staring region
of the arena and in an approximate cardinal direction, thus breaking the symmetry. At all
later times, the localizer uses the yaw estimated by the AHRS to break the symmetry and
feeds the yaw component of the estimated pose result back in to the AHRS to zero out the
accumulating error. Another function is a threaded component for carrying out a 3D scan
using the LIDAR and the gimbal. When queried, the 3D scanner repeatedly increases the
pitch on the gimbal and takes a 2D scan at each pre-defined angle. This results in a collection
of 2D scans that are then merged into a 3D map of the environment.
Finally, some Functional Layer functions make use of both the Backend and the
Autonomy hardware. Some examples are shown in Figure 5.34. One is the ability to go to
a point in the arena. This utilizes both the drive functionality of the platform along with
the localizer component to keep the platform driving toward the goal and to know when
the platform has arrived. A path following component takes in a list of desired positions
and utilizes the previous functionality to follow a specific path. The previously mentioned
excavate functionality also falls under this category.
Executive Layer
Client Layer Autonomy Hardware Interface Layer
Go To
Follow PathExcavate
LocalizeDriveGet Weight Raise Digger . . .
Figure 5.34: MARTE Autonomy Functional Layer: All Hardware
69
The Executive and Planning layers make all the high-level decisions on how to utilize
the Functional Layer to complete its mission. In MARTE’s case, there is only one mission,
to complete NASA RMC competition runs. The beginning of the Autonomy subsystem
section already briefly covered the general strategy of the Autonomy system. This strategy
was implemented as a basic state machine (Figure 5.35). In this case, the state machine as
a whole is part of the Planning Layer and the implementation of the individual states are
contained within the Executive Layer. The overall state machine decides what tasks (states)
should be carried out and in what order to complete a run while each state determines how
to utilize the components of the Functional Layer.
This design is heavily driven by the Executive Layer. Aside from state transitions,
all operation from the Autonomy system is controlled by the states in the Executive Layer.
Other aspects of the Planning Layer, such as a path planning algorithm based on A* and
an obstacle detection algorithm based on RANSAC, do not drive the system but instead are
invoked by the Executive Layer when needed.
70
Initial Localization
Prepare for Scan
Scan for Obstacles
Detect Obstacles
Plan Path
Cross Obstacle Area
Excavate
Plan Path
Cross Obstacle Area
Dock
Deposit
Decouple
Figure 5.35: MARTE Autonomy State Machine
71
5.4 Results
RAMP was successfully implemented on the MARTE platform for the 2014 NASA
RMC. The final MARTE platform using the Base and BLE modules and the Autonomy
subsystem is shown in Figure 5.36. The computational hardware for each subsystem and
module were physically mounted and enclosed in separate boxes while external sensors were
attached directly to their respective module or, in the case of Autonomy, free to be attached
to the platform depending on the modules in use.
Figure 5.36: MARTE Final Implementation
The modularity of the architecture was found to be beneficial, not just from an appli-
cation standpoint, but during the development cycle of the computational system. Design
and development of the Base module, BLE module, and computation system all took place
concurrently meaning the finalized Base and BLE modules were not available for use in early
software testing, in particular Autonomy testing. Instead of designing and using simulation
72
for Autonomy testing, the previous year’s drive train and hardware were used as a test
platform while development of the MARTE Base module was still in progress. An imple-
mentation of the Backend subsystem was used on the test platform. The implementation of
the testing platform’s Functional Layer had specific implementation details for the testing
platform, but the testing Backend provided identical requests and responses as would be
used on MARTE. Through this, the Autonomy subsystem could talk to the testing Backend
and control the testing platform using the same interface as the finalized MARTE Backend
would provide (Figure 5.37). Once the MARTE Base and Backend were completed, Auton-
omy testing was shifted from the testing platform to the MARTE Base with few integration
issues due to the identical Backend interface.
Figure 5.37: Autonomy Testing on the Test Base Module
Similarly, the ability to remove the Autonomy subsystem was also beneficial. The
autonomous hardware and sensors can be completely removed from the MARTE platform
during bench-top testing without making the system inoperable. This allowed Autonomy
testing to occur concurrently to operator training with the Frontend and MARTE.
The results of the six competition runs at the NASA RMC are shown in Table 5.7.
Every run in the competition arena was able to successfully collect above and beyond the
regolith necessary to qualify, even in the two cases in which the control had to be swapped
73
from autonomous to teleoperated mid-run. In addition, MARTE stood out as the only
competition robot able to successfully detect and avoid obstacles during a fully autonomous
run.
Figure 5.38 shows the 2D LIDAR scan collected for localization just prior to scanning
for obstacles during the fifth run. The data points clearly show the walls of the arena and
the small cloud of distance measurements that captured the BLE frame and dust. Figure
5.39 shows the two best-match poses for the previous scan (in the LIDAR sensor frame of
reference.) One is the correct pose while the other is a mirror due to the arena’s symmetry.
The incorrect pose was discard by additional data provided by the AHRS. Figure 5.40 shows
the result of obstacle detection and path planning following the 3D LIDAR scan, wherein
possible rocks, walls, and craters are marked. In this particular example, the rock and crater
in the “upper” half of the arena were accurately detected and mapped but the “lower” half
detected too much of the terrain as craters: a false positive. The small obstacle detected
beside the robot is caused by dirt piling up as the robot makes a zero degree turn. It is not
taken into account by path planning. Figure 5.41 shows the robot midway through execu-
tion of the path previously depicted, neatly driving between the rock and crater detected.
Finally, Figures 5.42 and 5.43 show MARTE during the collection and depositing processes,
respectively, during the third run.
74
Run #1 May 19, 2014 Qualified: Yes Teleoperation/AutonomyThe run began under autonomous control. The system successfully initialized,scanned for and detected obstacles, and began crossing the obstacle region, avoid-ing obstacles. Once reaching the digging area, the accumulating error of the AHRSled to sufficient drift of the pitch and roll of the LIDAR’s gimbal to lose the neces-sary range measurements to the arena walls, thus losing localization. Control wasswapped to teleoperation control and the run was successfully completed by the op-erators. Additional status monitoring and error handling was added after the run tohandle similar situations in future runs.
Run #2 May 20, 2014 Qualified: Yes TeleoperationThe entire run was completed successfully under teleoperated control.
Run #3 May 20, 2014 Qualified: Yes AutonomyThe entire run was completed successfully under autonomous control.
Run #4 May 21, 2014 Qualified: Yes Teleoperation/AutonomyThe run successfully reached the digging region autonomously before failing to localizeand recover. Control was transferred to the teleoperators and the run was successfullycompleted. Post-run analysis revealed that the IMU and vibration dampening mounthad shifted during operation leading to an invalid gravity vector and, therefore, invalidgimbal set-point causing a permanent tilt and roll such that the LIDAR could notdetect the arena’s walls for localization. The IMU mount was further secured followingthe run.
Run #5 May 23, 2014 Qualified: Yes AutonomyThe entire run was completed successfully under autonomous control.
Run #6 May 23, 2014 Qualified: Yes AutonomyThe entire run was completed successfully under autonomous control.
Table 5.7: NASA RMC Results
75
Figure 5.38: Run #5: Localization Scan
Figure 5.39: Run #5: Localization Result
76
Figure 5.40: Run #5: Path Planning
77
Fig
ure
5.41
:R
un
#5:
Auto
nom
ousl
yC
ross
ing
78
Fig
ure
5.42
:R
un
#3:
Auto
nom
ousl
yD
iggi
ng
79
Fig
ure
5.43
:R
un
#3:
Auto
nom
ousl
yU
nlo
adin
g
80
CHAPTER 6
CONCLUSIONS
In conclusion, this thesis presents RAMP, a robotic architecture for a modular plat-
form that supports either teleoperated or autonomous control. RAMP is closely related
to three-tiered hybrid autonomous architectures but places special emphasis on the neces-
sary design requirements and implementation details needed to support a modular robotic
platform and the ability to remove the autonomous components from the system while pre-
serving teleoperation capabilities. RAMP consists of three distinct subsystems: a Backend
for managing the robotic platform, a Frontend for interacting with the human operator dur-
ing teleoperation, and Autonomy for autonomously operating the system. This division of
subsystems allows the Autonomy components to be completely removed from the overall
system without affecting the operator’s ability to control the platform through the Backend.
The subsystems are further broken down into the layers necessary for supporting a platform
of removable and interchangeable modules. The architecture was successfully implemented
on the MARTE platform as part of the 2014 NASA RMC. The modularity of the architec-
ture was found to be very useful during the development process. Additionally, the ability
to swap between teleoperation and autonomous control was essential. Also, decoupling tele-
operation from autonomy allows MARTE to operate without the Autonomy hardware to
reduce weight when autonomous operation is not needed.
Various future modifications could be made to improve RAMP. One beneficial addi-
tion would be the inclusion of a new subsystem and layers to support interaction between a
remote operator and the Autonomy subsystem. This could allow a remote operator to receive
and monitor autonomy-related status. This display subsystem would provide substantial
81
improvements for operators unfamiliar with the implementation details of the Autonomy
subsystem; allowing them to make better decisions on when they should intervene and take
over control of the robot’s operation.
Another improvement would be a standardized interface for communication between
modules within the Backend. The current implementation does not define a specific means
for allowing one module to query the status of another. This would be beneficial in situations
where, for example, one module’s movement may be restricted by the position of another
module to avoid collisions between onboard hardware.
Another possible extension to RAMP would be the addition of support for multi-
robot applications. Perhaps, in such a system, RAMP would benefit from a new layer or
subsystem that communicates and supervises many autonomous, modular platforms, each
of these platforms running the extended version of RAMP mentioned previously that allows
mission-level commands. Or, alternatively, the addition of a supervisor subsystem that
directly controls the individual robots through the same Backend interface that the Frontend
and Autonomy subsystems use. There would also be the question of how to handle the ability
to remove the autonomy module from platforms in such a system. A heterogeneous system
consisting of some robots having an autonomy module and some without an autonomy
module would complicate the design.
Finally, an excavation rover was presented in this thesis but other modular platforms
are also supported. Analysis and improvement of RAMP would include new case studies on
additional platforms designed for other applications and environments.
82
REFERENCES
[1] R. R. Murphy, Introduction to AI Robotics. Cambridge, MA: MIT Press, 2000.
[2] R. Siegwart et al., Introduction to Autonomous Mobile Robots, 2nd ed. Cambridge,MA: The MIT Press, 2011.
[3] B. P. Gerkey et al., “The Player/Stage Project: Tools for multi-robot and distributedsensor systems,” in International Conference on Advanced Robotics, 2003, pp. 317–323.
[4] B. P. Gerkey et al. (2014) The player project. [Accessed: 2015-01-31]. [Online].Available: http://playerstage.sourceforge.net/
[5] Willow Garage. (2014) ROS: Robot operating system. [Accessed: 2015-01-31]. [Online].Available: http://www.ros.org
[6] B. Alvarez et al., “Reference architecture for robot teleoperation: Development detailsand practical use,” Control Engineering Practice, vol. 9, no. 4, pp. 395–402, 2001.
[7] A. Iborra et al., “Robotized system for retrieving fallen objects within the reactor vesselof a nuclear power plant (PWR),” in 2000 IEEE International Symposium on IndustrialElectronics, vol. 2, 2000, pp. 529–534.
[8] J. S. Albus et al., “NIST technical note 1235: NASA/NBS standard reference modelfor telerobot control system architecture (NASREM),” National Institute of Standardsand Technology, Gaithersburg, MD, Tech. Rep., 1989.
[9] S. Leake et al., “Hierarchical ada robot programming system (HARPS): A complete andworking telerobot control system based on the NASREM model,” in IEEE InternationalConference on Robotics and Automation, vol. 2, 1989, pp. 1022–1028.
[10] B. Ressa et al., “A NASREM based architecture for robot control in the sanitary landfillstudy case,” Fifth International Conference on Advanced Robotics, vol. 2, pp. 1299–1304,1991.
[11] R. H. Byrne, “A practical implementation of a hierarchical control system for teleroboticland vehicles,” National Telesystems Conference, 1992.
[12] R. A. Brooks, “A robust layered control system for a mobile robot,” IEEE Journal ofRobotics and Automation, vol. 2, no. 1, pp. 14–23, 1986.
[13] R. A. Brooks and A. M. Flynn, “Robot beings,” in IEEE/RSJ International Workshopon Intelligent Robots and Systems ’89, 1989, pp. 2–10.
83
[14] J. Connell, “A colony architecture for an artificial creature,” Ph.D. dissertation, MIT,1989.
[15] E. Gat et al., “Behavior control for robotic exploration of planetary surfaces,” IEEETransactions on Robotics and Automation, vol. 10, no. 4, pp. 490–503, 1994.
[16] R. C. Arkin and T. Bulch, “AuRA: Principles and practice in review,” Journal ofExperimental and Theoretical Artificial Intelligence, vol. 9, pp. 175–189, 1997.
[17] R. C. Arkin, “Motor schema based navigation for a mobile robot: An approach toprogramming by behavior,” in 1987 IEEE Conference on Robotics and Automation,1987, pp. 264–271.
[18] E. Gat, “Integrating planning and reacting in a heterogenous asynchronous architec-ture for controlling real-world mobile robots,” in 10th National Conference on ArtificialIntellegence, ser. AAAI’92, 1992, pp. 809–815.
[19] R. J. Firby, “An investigation into reactive planning in complex domains,” in SixthNational Conference on Artificial Intelligence, vol. 1, 1987, pp. 202–206.
[20] R. P. Bonasso et al., “Experiences with an architecture for intellegent, reactive agents,”Journal of Experimental and Theoretical Artificial Intelligence, vol. 9, pp. 237–256, 1995.
[21] R. P. Bonasso, “Using the 3T architecture for tracking shuttle RMS procedures,” inIEEE International Joint Symposium on Intelligence and Systems, 1998, pp. 180–187.
[22] R. Alami et al., “An architecture for autonomy,” INTERNATIONAL JOURNAL OFROBOTICS RESEARCH, vol. 17, pp. 315–337, 1998.
[23] F. Qureshi et al., “The cognitive controller: A hybrid deliberative/reactive control ar-chitecture for autonomous robots,” in 17th International Conference on Innovations inApplied Artificial Intelligence, 2004, pp. 1102–1111.
[24] B. Pell et al., “An autonomous spacecraft agent prototype,” in Autonomous Robots,1997, pp. 253–261.
[25] R.Volpe et al., “The CLARAty architecture for robotic autonomy,” in IEEE AerospaceConference, vol. 1, 2001, pp. 121–132.
[26] M. G. Bualat and L. Kobayashi, “Flexible rover architecture for science instrumentintegration and testing,” in AIAA Space 2006, 2006.
[27] D. M. Lyons and A. J. Hendriks, “Planning as incremental adaption of a reactive sys-tem,” Robotics and Autonomous Systems, vol. 14, pp. 255–288, 1995.
[28] R. Simmons, “Concurrent planning and execution for autonomous robots,” IEEE Con-trol Systems, vol. 12, no. 1, pp. 46–50, 1992.
[29] K. Konolige et al., “The saphira architecture: A design for autonomy,” Journal ofExperimental and Theoretical Artificial Intelligence, vol. 9, pp. 215–235, 1997.
84
[30] J. H. Connell, “SSS: A hybrid architecture applied to robot navigation,” in IEEE In-ternational Conference on Robotics and Automation, vol. 3, 1992, pp. 2719–2724.
[31] NASA, “NASA’s fifth annual robotic mining competition: Rules & rubrics 2014,” 2014,unpublished.
[32] C. Leslie et al., “Alabama astrobotics: 2014 systems engineering paper,” 2014, unpub-lished.
[33] PolarCloud. (2010) Tomato firmware version 1.28. [Accessed: 2014-10-17]. [Online].Available: http://www.polarcloud.com/tomato
[34] A. Weiss. (2009) How to: Set Tomato firmware for wireless client modes. [Accessed:2014-10-17]. [Online]. Available: http://www.wi-fiplanet.com/tutorials/article.php/3810281
[35] Phidgets. (2014) 1072 0 - PhidgetSBC2. [Accessed: 2014-10-17]. [Online]. Available:http://www.phidgets.com/products.php?product id=1072 0
[36] Linksys. (2014) WRT54G support. [Accessed: 2014-10-17]. [Online]. Available:http://support.linksys.com/en-us/support/routers/WRT54G
[37] IEEE and The Open Group. (2013) The open group base specifications issue7: System interfaces: Detailed ToC. [Accessed: 2014-08-17]. [Online]. Available:http://pubs.opengroup.org/onlinepubs/9699919799/functions/contents.html
[38] Dimension Engineering. (2014) Sabertooth 2X60 regenerative dual motor driver.[Accessed: 2014-10-23]. [Online]. Available: https://www.dimensionengineering.com/products/sabertooth2x60
[39] Phidgets. (2014) 1135 0 - precision voltage sensor. [Accessed: 2014-10-23]. [Online].Available: http://www.phidgets.com/products.php?category=8&product id=1135 0
[40] Phidgets. (2014) Language - C/C++ - Phidgets support. [Accessed: 2014-10-23].[Online]. Available: http://www.phidgets.com/docs/Language - C/C%2B%2B
[41] Alphathon and Wikipedia. (2010) 360 controller. [Accessed: 2014-10-26]. [Online].Available: http://upload.wikimedia.org/wikipedia/commons/2/2c/360 controller.svg
[42] Hokuyo Automatic. (2012) UTM-30LX-EW. [Accessed: 2014-11-02]. [Online]. Available:http://www.hokuyo-aut.jp/02sensor/07scanner/download/products/utm-30lx-ew/
[43] ServoCity. (2014) SPT200 pan & tilt system. [Accessed: 2014-11-02]. [Online].Available: http://www.servocity.com/html/spt200 pan tilt system.html
[44] ServoCity. (2014) HS-5645MG digital torque. [Accessed: 2014-11-02]. [Online].Available: http://www.servocity.com/html/hs-5645mg digital torque.html
85
[45] Phidgets. (2014) 1044 0 - PhidgetSpatial precision 3/3/3 high resolution. [Accessed:2014-11-02]. [Online]. Available: http://www.phidgets.com/products.php?category=5&product id=1044 0
[46] VIA Embedded. (2014) EPIA-P900. [Accessed: 2014-11-02]. [Online]. Available:http://www.viaembedded.com/en/products/boards/1670/1/EPIA-P900.html
[47] Phidgets. (2014) 1061 1 - PhidgetAdvancedServo 8-motor. [Accessed: 2014-11-02].[Online]. Available: http://www.phidgets.com/products.php?category=11&productid=1061 1
[48] Hokuyo Automatic. UTM-30LX-EW communication protocol specification rev 1.0.[Accessed: 2014-11-02]. [Online]. Available: http://www.hokuyo-aut.jp/02sensor/07scanner/download/pdf/UTM-30LX-EW protocol en.pdf
[49] (2013) URG helper version 1.0.4. [Accessed: 2014-11-02]. [Online]. Available:http://sourceforge.net/projects/urgwidget/
86