Citation
Design and implementation of an intelligent primitive driver

Material Information

Title:
Design and implementation of an intelligent primitive driver
Creator:
Vinch, Peter M. ( Author, Primary )
Publication Date:
Copyright Date:
2003

Subjects

Subjects / Keywords:
Compasses ( jstor )
Control systems ( jstor )
Error rates ( jstor )
Geometric angles ( jstor )
Intelligent vehicles ( jstor )
Robots ( jstor )
Sensors ( jstor )
Staircases ( jstor )
Stairs ( jstor )
Wrenches ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Vinch, Peter M.. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
9/9/1999
Resource Identifier:
53345045 ( OCLC )

Downloads

This item has the following downloads:

PDF ( 2 MBs ) ( .pdf )

vinch_p_Page_01.txt

vinch_p_Page_50.txt

vinch_p_Page_70.txt

vinch_p_Page_52.txt

vinch_p_Page_77.txt

vinch_p_Page_33.txt

vinch_p_Page_10.txt

vinch_p_Page_39.txt

vinch_p_Page_66.txt

vinch_p_Page_21.txt

vinch_p_Page_32.txt

vinch_p_Page_83.txt

vinch_p_Page_31.txt

vinch_p_Page_69.txt

vinch_p_Page_09.txt

vinch_p_Page_14.txt

vinch_p_Page_44.txt

vinch_p_Page_71.txt

vinch_p_Page_27.txt

vinch_p_Page_76.txt

vinch_p_Page_61.txt

vinch_p_Page_07.txt

vinch_p_Page_47.txt

vinch_p_Page_74.txt

vinch_p_Page_08.txt

vinch_p_Page_43.txt

vinch_p_Page_35.txt

vinch_p_Page_19.txt

vinch_p_Page_42.txt

vinch_p_Page_81.txt

vinch_p_Page_23.txt

vinch_p_Page_22.txt

vinch_p_Page_38.txt

vinch_p_Page_56.txt

vinch_p_Page_37.txt

vinch_p_Page_49.txt

vinch_p_Page_55.txt

vinch_p_Page_78.txt

vinch_p_Page_84.txt

vinch_p_Page_68.txt

vinch_p_Page_80.txt

vinch_p_Page_63.txt

vinch_p_Page_62.txt

vinch_p_Page_64.txt

vinch_p_Page_48.txt

vinch_p_Page_18.txt

vinch_p_Page_03.txt

vinch_p_Page_05.txt

vinch_p_Page_30.txt

vinch_p_Page_41.txt

vinch_p_Page_28.txt

vinch_p_Page_59.txt

vinch_p_Page_24.txt

vinch_p_Page_73.txt

vinch_p_Page_54.txt

vinch_p_Page_02.txt

vinch_p_Page_04.txt

vinch_p_Page_29.txt

vinch_p_Page_72.txt

vinch_p_Page_15.txt

vinch_p_Page_26.txt

vinch_p_Page_11.txt

vinch_p_Page_60.txt

vinch_p_Page_79.txt

vinch_p_Page_57.txt

vinch_p_Page_25.txt

vinch_p_Page_67.txt

vinch_p_Page_58.txt

vinch_p_Page_40.txt

vinch_p_Page_46.txt

vinch_p_Page_16.txt

vinch_p_Page_51.txt

vinch_p_Page_36.txt

vinch_p_Page_75.txt

vinch_p_pdf.txt

vinch_p_Page_17.txt

vinch_p_Page_82.txt

vinch_p_Page_12.txt

vinch_p_Page_65.txt

vinch_p_Page_13.txt

vinch_p_Page_53.txt

vinch_p_Page_34.txt

vinch_p_Page_20.txt

vinch_p_Page_06.txt

vinch_p_Page_45.txt


Full Text











DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER


By

PETER M. VINCH, JR.


















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003




























Copyright 2003

by

Peter M. Vinch, Jr.





























"What we call the beginning is often the end. And to make an end is to make a beginning.
The end is where we start from."
T.S. Eliot, "Four Quartets"















ACKNOWLEDGMENTS

There are many individuals, on professional and personal fronts, whom I would like to

thank for making possible the preparation and completion of this thesis. Professionally, I

would like to thank Dr. Carl D. Crane, III (my academic advisor and chair of my graduate

committee) for his direction, advice and encouragement. I also greatly appreciate the time

and energy that the other members of my supervisory committee (Dr. John K. Schueller

and Dr. Eric M. Scwartz) dedicated to my cause. I would like to extend my gratitude to

the Nuclear and Radiological Engineering Department of the University of Florida for

allowing me the use of their Remotec Andros robot for testing purposes. I thank the U.S.

Department of Energy (Grant #DE-FG04-86NE37967) and the Air Force Research

Laboratory located at Tyndall Air Force Base, Florida (contract # F08637-00-C6008) for

all of their support. I am also grateful to the entire staff of the Center for Intelligent

Machines and Robotics, for all of their assistance with the completion of my thesis.

Additionally, I would like to distinguish the contributions of Shannon Ridgeway, Daniel

Kent, Carl P. Evans, III, and especially Dr. David Keith Novick for all of their

professional advice and the friendship that they have extended to me. Without these

individuals, none of this would have been possible.

Personally, I would like to thank all of my friends and family for their efforts to keep

me sane and functional. Key people in this effort were Andrew and Gretchen McGraw,

whose friendship, support and love I will always value. I would also like to thank Adam

Feinberg for being such a great roommate, lifting partner, and best friend. He has pushed









me to become better in every aspect of my life; and for this I will always be grateful. Of

course, without the love and support of my family, all of my efforts would be fruitless.

Therefore, I would like to thank my mother, Nancy; my two sisters, Bridget and Melissa;

and my grandfather, Philip. Finally, I would like to thank my father, Peter M. Vinch, Sr.;

and my uncle, Robert Frie. These men have been my greatest influences, helping to place

me on the proper path through life. Without them, I would have been lost.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ......... ............... ................................................................... iv

LIST OF TABLES ........................... ...... ........ ................... viii

LIST OF FIGURES ......... ......................... ...... ........ ............ ix

ABSTRACT ........ .............. ............. ...... ...................... xi

CHAPTERS

1 INTRODUCTION AND BACKGROUND ...................................... ................

1 .1 In tro d u ctio n ............. .. ............. ........................................................................... 1
1.2 Background ............. .............. ............. 1
1.2.1 A assisted Teleop Control .......................... ...... .. ................................ 1
1.2.2 Stair Clim bing ........................................ 3
1.3 The Joint Architecture for Unmanned Systems (JAUS)................ .................... 4
1.3 .1 O v erv iew ................................................................ ............................. . 4
1.3.2 System Topology.............................. .............. 6
1.3.3 The JA U S C om ponent.............................................. ........................... 7
1.3 .4 T h e JA U S M essag e ......................................................................................... 7

2 TEST PLATFORM DEVELOPMENT .............. ...................... .............. 10

2.1 R em otec A ndros R obot..................... ...................................... .......................... 10
2.2 A ndros JA U S C ontroller................................................... .......................... 12
2.3 Sensor System s ........................................................ ......... 15
2 .3.1 Stair C ounter A ssem bly ....................................................... ... ................. 15
2.3.2 Auxiliary Track Positioning System ..................................................... 20
2.3.3 JA U S Positioning System ........................................ .................. ...... 21
2.4 O operator C control U nit ........................................................... ... .............. 22

3 INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION............24

3 .1 C om p on ent D definition ............................................................................................ 24
3.1.1 Com ponent Function ..................................................... .................. 24
3.1.2 Com ponent I/O ................................................... ... .. ........ .. 24
3.1.3 C om ponent D description ....................................................... ... ................. 25









3.1.4 IPD Input and Output M messages ........... ................................... 27
3.1.4.1 "Set Auxiliary Actuators" ............. ..... .... ..................27
3.1.4.2 "Query Auxiliary Actuators" ................................... ............... 28
3.1.4.3 "Report Auxiliary Actuators" .................................. ...............28
3.1.4.4 "Set B behavior X .......................................................................... 28
3.1.4.5 "Query B behavior X ........................ ............................................. 29
3.1.4.6 "R report Behavior X ........................ ............................................29
3.2 Intelligent Prim itive D river Application............... ......................... ....... ....... 30
3.2.1 Fuzzy Logic ............... .... ......... ......... ........ 30
3.2.2 Functionality.................. ............................. 31
3.2.3 Program Logic ......... ..... ........ .. .. ........ ..... .............. 32
3.2.4 A scend Protocol 1 .................... ................. ...................... .............. 39
3.2.5 A scend Protocol 2 .................... ................. .................... .............. 39
3.2.6 Descend Protocol 1 ....... ........ .... .................................... .......... .. 41
3.2.7 D escend P rotocol 2 .............................................................. .............. 42

4 TESTING AND RESULTS ........................................................................ 43

4.1 Stair-C ounter A ssem bly ....................................................................... 43
4.1.1 Testing Procedure ............................................. .. .. .. ............ .. 43
4.1.2 R results ...................... ............ ........ 46
4.2 Auxiliary Track Positioning System ............................................... ................. 48
4.2.1 Testing Procedure .......................................... ..... ........... .... ........ 48
4.2.2 Results ........................... ........ .............. 50
4.3 H leading A lignm ent Controller ........................................ ......................... 52
4.3.1 Testing Procedure ............................................. .. .. .. ............ .. 52
4.3.2 R results ......................................... 52

5 CONCLUSIONS AND FUTURE WORK ...........................................................55

5.1 C onclu sions........................................... 55
5 .2 F u tu re W ork ..................................................................... 59

APPENDIX

A. STANDARD JAUS M ESSAGES ........................................ .......................... 61

A.1 Query Global Pose .. ................. ........................ ................ 61
A .2 Set W rench E effort .................................................... .................................. 61
A .3 JA U S C ore M message Set .......................................................................... .... 63

B. STAIR COUNTER MATHEMATICAL DEVELOPMENT ............................... 64

L IST O F R E F E R E N C E S ........................................................................ .....................69

B IO G R A PH IC A L SK E T C H ..................................................................... ..................71
















LIST OF TABLES

Table page

1-1 M message header data form at ............................................... ............................ 8

3-1 User defined input and output JAUS commands..........................................25

3-2 "Set Auxiliary Actuators" command fields.............. ....... ................27

3-3 "Query Auxiliary Actuators" command field................................ ............... 28

3-4 "Set Behavior X" com m and fields ........................................ ........ ............... 29

3-5 "Query Behavior X" command field ............................ .................................... 29

3-6 "Set Behavior" 1 and 2 control data ........................................ ...... ............... 32

A -i "Query G lobal Pose" data field ........................................ .......................... 61

A-2 "Set Wrench Effort" data fields .............. ............. ............... 62

A -3 Core m message set........ ...... .............................. ...... ............................. 63
















LIST OF FIGURES

Figure page

1-1 A architecture hierarchy .............................................................. ...... ... .

1-2 M message header properties bit layout ........................................ ...... ............... 9

2-1 Rem otec Andros robotic platform ......................................................................10

2-2 Andros physical dimensions ........... ..... ......... .... ............... 11

2-3 N active A ndros controller ......... ................. ..........................................................12

2-4 Communicator-Node Manager component interaction ........................... .........13

2-5 Primitive Driver component interaction..... ................... ...............14

2-6 Vehicle orthogonal coordinate system ........................................ ............... 15

2-7 Stair counter assem bly .......... ................... ....... ...................... ............... 16

2-9 M edian filter exam ple....................................................................... ..................18

2-10 Auxiliary track position system setup ........................................... ............... 20

3-1 Intelligent Primitive Driver implementation ................................. ................ 26

3-2 Intelligent Primitive Driver logic flow diagram.............. ..... .................33

3-3 "Set Auxiliary Actuator" algorithm .................................................. ............... 34

3-4 Opening sequence of "Set Behavior X" algorithm............................................35

3-5 Stair data representation ........................................ .............................................36

3-6 Skew alignm ent task correction........................................ ............................ 37

3-7 A scend stair m otion protocol....................................... ............... ............... 40

3-8 D escend stair m otion protocol ............................................................ ............ 41

4-1 Calibration data for Sharp GP2D12 infrared object detectors..............................44









4-2 Stair-counter testing assem bly........................................................ ............... 45

4-3 Stair-counter data........... ........ ........................................ ............ 47

4-4 Plumb compass attached to Andros auxiliary track...............................................48

4-5 Controller commanded halt angle and actuator halt angle versus operator
commanded angle.................... .................... ............ 50

4-6 Controller commanded halt error and actuator halt error versus operator
com m anded angle ............ ... ...................................................................... .. 5 1

4-7 Controller commanded halt heading and vehicle halt heading versus operator
com m anded heading ............. .. ............. ............ ...... ........ ............... 53

4-8 Controller commanded heading error and vehicle heading error versus operator
com m anded heading ............. .. ............. ............ ...... ........ ............... 54

5-1 Controller mounted on Andros platform ...................................... ............... 56

B -l Stair representation ........................... ............................ .. ........ .... ..... ...... 64

B-2 Stair runner model ............. .............. ................ .... ..... 65

B -3 Stair riser m odel .................. ................................. ..... ..... .. ........ 67

B-4 Calculated distances, d, for varying value of y..................................... .................68















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER

By

Peter M. Vinch, Jr.

August 2003

Chair: Carl D. Crane, III
Department: Mechanical and Aerospace Engineering

An Intelligent Primitive Driver (IPD) was designed to supplement the control of a

Primitive Driver component that is defined in the Department of Defense Joint

Architecture for Unmanned Systems (JAUS). Whereas the Primitive Driver component

accepts and blindly executes wrench commands, the IPD uses various subsystems to

provide it with the necessary information to make low-level decisions concerning vehicle

control. The IPD is accessible by either an onboard autonomous control system; or by a

tele-operational control system. Tele-operational control (teleop) is characterized by the

direct control of a platform by a human operator. For the case of an autonomous control

system, the IPD reduces high-level control responsibilities; and therefore reduces

processor demands. In the case of teleop control, the IPD serves to ease operator burden

by automating intensive operator-controlled processes.

The test platform for the functionality of the Intelligent Primitive Driver was a

Remotec ANDROS robot. In the case of the ANDROS robot, the IPD automates the

process of maneuvering up or down a flight of stairs.


















CHAPTER 1
INTRODUCTION AND BACKGROUND

1.1 Introduction

The purpose of this research was to design and develop an experimental intelligence

component based on the Joint Architecture for Unmanned Systems (JAUS), currently

being developed in concert with the Department of Defense. This component will be

designated the Intelligent Primitive Driver (IPD) and will allow for assisted tele-

operational (teleop) control of a platform. Teleop control can be defined as the control of

a vehicle or robot by the direct input of a human operator. Assisted teleop is based upon

this concept, but includes additional computer control to supplement the operator's

control; intensive control procedures were automated to ease the burden on the operator.

The IPD accomplished this task by having direct control of any and all actuators that

directly affect the motion of the platform. A Remotec Andros robot, outfitted with a

JAUS-compliant controller, was used to test the viability of the IPD. In the case of the

Andros, the IPD automated the complicated stair ascending and descending operations.

1.2 Background

1.2.1 Assisted Teleop Control

The human-machine relationship has always been clearly defined: machines are

controlled by humans and are constructed to ease the burdens of human life. However,

two recently developing factors have begun to dramatically change this relationship.









First, an increase in computing power and system reliability along with a decrease in size

and power requirements of modem control systems have made possible the shift of some

control responsibility from the human operator to the controller itself. Bayouth and

colleagues [1] (of the Robotics Institute of Carnegie Mellon University) constructed an

autonomous roadway vehicle that demonstrated lane following, speed and heading

compliance, and obstacle avoidance in an effort to increase vehicle safety and mobility.

Several other groups have also worked on the "Intelligent Cruise Control" concept. The

Mustererkennung und Szenenanalyse Pattern Recognition and Scene Analysis (MESA)

research group [2] have developed behaviors (such as tracking a lead vehicle or lane

changing) that comprise a basic control set on which more complicated procedures are

based. Schlegel [3], in his thesis, "Autonomous Vehicle Control using Image

Processing," tested the intelligent cruise control notion through the use of scale models

coupled with a remote control station aimed at emulating full-scale vehicle controls.

The second factor that has influenced the human-machine interface is the growing

complexity of the platforms being automated and the tasks they are able to perform.

Connell and Viola [4] (of the IBM T.J. Watson Research Center) have a novel way of

describing the problems with traditional platform control systems:

"Consider the differences between riding a horse and driving an
automobile. A horse will not run into a telephone pole at high speed. If
you fall asleep in the saddle, a horse will continue to follow the path that it
is on.... In general, horses are much smarter than automobiles and thus
provide a better model for control of a mobile robot." [4]

Connell and Viola constructed a platform and control system that cast the operator as an

agent in the control system, able to input commands into the arbitration network, as well

as a high-level command language that was able to shut out individual control agents.









Huntsberger and Rose [5], of the Jet Propulsion Laboratory (JPL) and the University of

South Carolina (USC), respectively, are working on a behavior-based control system

named BISMARC, or the Biologically Inspired System for Map-based Autonomous

Rover Control, for use with the Mars rover platforms. They utilize a form of path

planning that is derived from the study of human navigation through complex

environments.

1.2.2 Stair Climbing

For mobile robotic platforms to be useful in urban environments, they need to be able

to easily traverse commonly found terrain features, such as stairways. Several detection

methods are used to enable platform navigation on these non-continuous planar structures

(such as vision-based positioning and edge detection, laser-based edge detection, and the

fusion of several sensor systems). Others have solved the dilemma by manipulating the

physical characteristics of the platform to suite the special needs of a stair-climbing

vehicle.

Matthies, et al. [6] constructed a small mobile platform capable of performing

reconnaissance duties in urban situations. To meet the stair climbing requirements

associated with this detail, a vision-guided navigation and detection system was

implemented on the robot. A stereovision system was used to detect the forward edges of

individual steps. This information was used to derive the angle of rotation between the

robot and the stairway; and to ensure that the robot was accurately following the stair

heading.

Lewis and Simo' [7] (Iguana Robotics, Inc.) built a bipedal platform based on the

biomorphic concept capable of stair travel (Figure 1-1). Basically, a biomorphic robot

attempts to mimic the sensory capabilities of animals; sensory input is predicated upon









voluntary movement of the platform and must be distinguished from possible inputs

produced by the platform itself. The platform fused stereovision; and tactile and pressure

sensors to build an accurate data model of the terrain to traverse.

Another application of the biomorphic concept is the work of Talebi, et al. [8]. They

constructed a quadruped platform that has only one actuator per leg coupled with

compliant prismatic joints. Therefore, as an animal would, the platform climbs a stair

dynamically. As the leg contacts the stair, ground forces cause the joint spring to

compress; and the effective length of the leg is reduced.

Perhaps the most stable solution for the stair-climbing problem, when the

development of the platform permits, is to tailor the geometry to accommodate the stair

climbing motion. Lauria, et al. [9] took this approach in developing their vehicle,

Octopus. The platform consists of eight motorized, tactile wheels and a tilt sensor; and

has a total of fifteen degrees of freedom. The platform geometry allows for all eight

wheels to be in contact with the ground at all times, regardless of the terrain profile;

allowing for relatively simple travel of the platform across any uneven terrain, stairways

included.

1.3 The Joint Architecture for Unmanned Systems (JAUS)

This section provides a functional description of the Joint Architecture for Unmanned

Systems (JAUS). The technical constraints on the architecture, system topology,

standard component definition, and the JAUS message will be discussed.

1.3.1 Overview

The JAUS architecture is being developed in conjunction with the Department of

Defense in support of unmanned vehicle systems development and provides a means for

reducing system life-cycle costs by offering a well-defined component interface. This









interface allows for the future reuse of expensive components in developing autonomous

systems and also allows for the quick exchange of malfunctioning or outdated

components in current autonomous systems. Further, the engineer is free to place all

available resources into obtaining optimal performance from the component as its

interface is predefined [10].

The JAUS architecture is divided into three separate volumes: the JAUS Domain

Model, Document Control Plan, and Reference Architecture. The JAUS Domain Model

defines both known and prospective operational requirements of unmanned systems,

while the Document Control Plan describes the procedure used to recognize and track

changes to accepted JAUS documents. This work will focus solely upon the Reference

Architecture as it is concerned with aspects of component design. The reference

architecture defines components, messages and standards that classify a system paradigm,

which allows for the assimilation of distributed system architectures. The reference

architecture is comprised only of components and messages that have been technically

evaluated by the tech base, academia, or an industry source and whose implementation is

thoroughly understood. Therefore, the incorporation of components, their classification,

and their corresponding messages is an evolutionary process [10].

There are four technical constraints, which have been levied upon the JAUS

architecture to ensure that it may be freely applied to any classification of unmanned

system. These constraints are platform independence, mission isolation, computer

hardware independence, and technological independence. To be platform independent,

no assumptions concerning vehicle platforms to be automated will be incorporated into

the definition of any JAUS component. The JAUS architecture defines a mission as the









ability to gather information about or to alter the state of the environment in which the

platform is operating. Therefore, the mission isolation constraint is intended to allow the

engineer to construct systems that can support a variety of missions, not just a single one.

The computer hardware independence constraint insists that the component be designed

independent of the computer system upon which the component will run. This was

included in the architecture so that currently used components can be applied to future

computer systems without modification to the component. This allows new computer

architectures to be easily inserted into current systems, extending its life cycle. This also

allows for hardware flexibility, as the appropriate hardware may be applied to each

system. Finally, technological independence is similar to computer hardware

independence, but instead deals with the action to be performed by the component instead

of the system that is performing the action. This constraint basically states that the

architecture will make no assumptions concerning the method by which an action is

performed. For example, in a JAUS compliant position system, no assumptions are made

concerning the method in which the vehicle position is obtained. Any method of

obtaining vehicle position is allowable, from a Global Positioning System (GPS), dead

reckoning, inertial measurement, a vision based position system, or any subsequent

positioning system [10].

1.3.2 System Topology

There are four elements, which comprise the hierarchy of the JAUS architecture: the

System, Subsystem, Node, and Component/Instance. A System is a logical grouping of

one or more Subsystems, which have been grouped such that beneficial cooperation

between the Subsystems can be achieved. A Subsystem is a distinct organism, which is

comprised of any number of Nodes necessary to form a complete unmanned system. A









Node is a distinct entity, comprised of a single processor or multiple processors working

in conjunction with each other, to provide a complete service. Finally, a Component is a

cohesive software process, which runs on a Node. An Instance is a single occurrence of a

Component running on a Node. Several Instances of the same Component may run on a

single Node, and are delineated by unique addresses. Figure 1-1 illustrates the interaction

of these four levels [10] .


SYSTEM





Node Node Node Node




Figure 1-1: Architecture hierarchy (used from JAUS: Reference Architecture
Specification, pg. 12)

1.3.3 The JAUS Component

As JAUS is a hierarchical system of components with standardized interfaces, the

JAUS Component is a strictly defined entity. A distinct name and identification number

defines a JAUS Component and every JAUS Component shall perform a single, cohesive

function. Each Component must be able to accept and act upon the set of core JAUS

command codes, as well as the input and output codes specific to the individual

Component itself. A list of the core JAUS command codes may be found in Appendix A

[10].

1.3.4 The JAUS Message

A JAUS message is comprised of two distinct components: the message header and

the message data buffer. The message header completely defines the message's









destination node, component, instance and subsystem identification, and the message's

corresponding source information. The message header also consists of the JAUS

command code, the number of bytes in the data buffer that the destination component can

expect to receive, and information pertaining to the message properties, such as the JAUS

architecture version being used. The message header data is found in Table 1-1 while the

bit field layout for the message properties can be seen in Figure 1-2.



Table 1-1: Message header data format (used from JAUS: Reference Architecture
Specification, pg. 54)
Field # Field Description Size (Bytes)
1 Message properties 2
2 Command code 2
3 Destination instance ID 1
4 Destination component ID 1
5 Destination node ID 1
6 Destination subsystem ID 1
7 Source instance ID 1
8 Source component ID 1
9 Source node ID 1
10 Source subsystem ID 1
11 Data control (bytes) 2
12 Sequence number 2
Total Bytes 16


The message data buffer is composed of packed JAUS control data. Each command

code has control data associated with it that is used by the system to command

component behavior. In an effort to reduce the size of the JAUS messages being

transmitted, and therefore reduce the required bandwidth of the system, the message data

is compressed before being transmitted. To accommodate this, the JAUS code library for











each component and its subsequent command codes must have the ability to pack and


unpack the control data.


Version
Range 0..63

Version 2.0 = (

Version 3.0 = 1

2..63 unused


15 14 13
Most significant bit


Cn C
CD CD
CD CD

on
1. R.

0 0
CD CD
0 0
oo

o3


o
0


0



in


Message Priority
Range 0..15

Default Priority 6

Normal Priority Range
0..11

Safety Critical Range
12..15

1 1 1


8 7 6 5 4 3 2 1 0
Least significant bit


Figure 1-2: Message header properties bit layout (used from JAUS: Reference
Architecture Specification, pg. 54)


C-o
O >
C"




'v















CHAPTER 2
TEST PLATFORM DEVELOPMENT

To investigate the Intelligent Primitive Driver, a test platform first needed to be

outfitted with a JAUS compliant control system. Due to the availability of indirect

motion actuators on the system and its relatively complicated stair climbing procedures, a

Remotec Andros robot was chosen for this task.

2.1 Remotec Andros Robot

Figure 2-1 depicts the Remotec Andros robot. As stated in the instruction manual, the

primary design purpose of the Andros is "to provide an effective means for remote

Explosive Ordnance Disposal (EOD)... Andros robots are currently used to remotely

perform a variety of hazardous work tasks including explosive handling, tactical support

operations, and nuclear plant maintenance" [11].













Figure 2-1: Remotec Andros robotic platform

The robot consists of a main chassis, front and rear sets of auxiliary tracks, and the

main arm assembly. The tracks are made of Kevlar belts with molded internal and

external urethane cleats. The auxiliary tracks are able to swing from +85 degrees to -65









degrees relative to the horizontal position. The drive motors are able to propel the

Andros up forty-five degree slopes or stairs and can maintain the vehicle's position upon

a slope through dynamic braking. The physical dimensions of the Andros are seen in

Figure 2-2 [11].













32" 28"

Figure 2-2: Andros physical dimensions

Figure 2-3 depicts the native Andros controller. Upon power up of the Andros

system, the native control transmits an initialization string to the Andros' embedded

controller and then begins the continuous output of the control data. The Andros'

embedded controller will only enter the "ready" state and accept platform control data if

the initialization string is properly sent and the control data is received at a maximum 5

Hz frequency. The controller uses a proprietary serial control stream to communicate

with the Andros' embedded controller. The update frequency is the absolute maximum

rate at which any controller may update the control data being sent to the Andros and

therefore alter the Andros' intended motion.

To use the Andros robot as the test platform for the IPD system, the JAUS control

system implemented on the Andros had to be completely removable from the system so

that the native Andros controller could be reconnected and used to control the Andros.









To meet this interoperability constraint, the JAUS control system mimicked the serial

control stream of the native controller. To achieve this, the control stream and

initialization string were reversed engineered from the output of the native controller;

however, the specific information pertaining to the Andros control data bytes may not be

disseminated because of a nondisclosure agreement entered into between the Center for

Intelligent Machines and Robotics (CIMAR) laboratory, located at the University of

Florida, and Remotec, the manufacturer of the Andros platform.












.... .. .. .






Figure 2-3: Native Andros controller

2.2 Andros JAUS Controller

The Andros JAUS controller operates on a RabbitCore RCM3200 microcontroller,

which utilizes a Rabbit 3000 microprocessor running at 44.2 MHz. The RCM3200 has

an integrated 10/100Base-T Ethernet port and six available serial ports for

communications, as well as 44 configurable, 5 volt tolerant, I/O lines. The RCM3200

runs the Dynamic C Premier Version 7.33P3 real time operating system, in which the

four basic JAUS components that comprise the Andros control system were coded.









These components are the Communicator, Node Manager, Primitive Driver, and Position

System. Libraries for each component were coded following the specifications found in

the JAUS Reference Architecture.



Node A Node B

Component A Component B



Node Manager Node Manager



Communicator) Ethernet Communicator

Figure 2-4: Communicator-Node Manager component interaction

Two JAUS components are directly responsible for all inter-component

communications: the Communicator and the Node Manager. As such, all nodes must

support both a Communicator and a Node Manager component. The Communicator

allows for a single point of message entry into a subsystem while maintaining the data

link between the subsystems. The Andros Communicator uses a User Datagram Protocol

(UDP) Ethernet connection for all communications. The Node Manager component

controls the routing of JAUS messages from one node to another. As depicted in Figure

2-4, a JAUS message is spawned within a component and then sent to the Node Manager,

where the information pertaining to the destination component and destination node are

attached to the message. This fully defined JAUS message is now passed on to the

communicator, which handles the transmission of the message to the proper node [10].























Vehicle Specific
ctuator Commands


Figure 2-5: Primitive Driver component interaction

The Primitive Driver is a component, which accepts wrench commands from the

System Commander and resolves them into vehicle specific actuator signals, thus

initiating vehicle motion, as seen in Figure 2-5. A wrench command consists of six

propulsive and six resistive elements, with each set consisting of three linear force

elements and three rotational moment elements. These elements are then mapped to the

three axis orthogonal coordinate system assigned to the vehicle, as shown in Figure 2-6.

It is worth noting that every element of a wrench message is not necessarily applicable to

every vehicle. For example, a wheeled vehicle typically only requires three elements of

the wrench message to control it properly: the resistive and propulsive linear forces in the

x direction and the rotational moment in the z direction [10].









The Position System is concerned solely with the determination of the vehicle's

global position and orientation and is necessary for the controller to perform accurate

autonomous motion. The vehicle's position and orientation information is provided to

the system upon receipt of a "Query Global Pose" command from either the Operator

Control Unit or the Intelligent Primitive Driver.








Ground Plane






Figure 2-6: Vehicle orthogonal coordinate system

2.3 Sensor Systems

There are three main sensor systems used by the Andros system: the stair counter

assembly, the auxiliary track position system, and the JAUS positioning system. These

systems provide feedback essential to the controller's ability to execute behavioral

commands.

2.3.1 Stair Counter Assembly

For the stair-climbing algorithms to function properly, the control system needs to

know the relative position of the Andros on the stairs. Typically, a Global Positioning

System (GPS) would be used to provide location information in a robotic system.

However, staircases are found in or around buildings, which generally limit the

effectiveness of a GPS system; if satellite transmissions to the GPS receiver are blocked









by the structure housing the staircase, no position information will be acquired.

Therefore, the stair counter assembly was designed to provide the relative position of the

Andros upon the staircase by counting the number of stairs that the Andros has passed

and is able to account for a step while moving in either direction upon a staircase. For

example, while climbing the stairs, the Andros passes four steps. While attempting to

move to the fifth step, a slippage error occurs and the Andros slides back down two steps.

The stair counter is able to take this error into account and update the current position of

the Andros upon the stairs. In this case, the Andros would now be located at the second

step.

Mounting Plate



infrared
Sensors





\ Shroud












Figure 2-7: Stair counter assembly

The stair counter assembly consists of an array of two Sharp GP2D 12 infrared object

detectors. These sensors take continuous distance readings up to 80 cm, have an update










rate of 31.25 Hz, and are interfaced by the RabbitCore microcontroller through the use of

a TLC545 Texas Instruments analog-to-digital converter. The sensors are positioned one

in front of the other with a one-inch offset and are orientated such that their detection

beams are perpendicular to the long axis of the Andros, as seen in Figure 2-7; the sensors

point directly at the plane upon which the Andros is situated. Both sensors are shrouded

to limit the amount of interference they may receive from ambient light sources and from

each other.




0.4


0.2


0
S4.5 5 5.5 6 65

-0.2


.: -0.4


-. Impulse
mn -0.6
a *


-0.8


-1
Stair Data *
1st Derivative
-1.2
2nd Derivative

-1.4
Time (sec)

Figure 2-8: Infrared sensor stair representation








Each infrared sensor constructs a digital representation of the staircase as the Andros

moves on it by determining the distance from the sensor to the staircase. By assuming

that the vehicle maintains a relatively constant velocity upon the staircase, the derivative

of the stair data can be found by simply taking the difference of the current data point and

the previous data point collected. The second derivative of the stair data can now be

obtained by taking the difference of the first derivative data. Figure 2-8 depicts a sample

stair data representation for a single infrared detector and the corresponding first and

second derivative data. The graph has been cropped to emphasize the range of pertinent

data. The data for the stair representation was simulated using a mathematical model of

the sensor system, with the first and second derivative data obtained as outlined above.

For the simulation, the rise of a single step was set at 8 inches, the run was set at 10

inches, and a 0.1 second sampling rate was used. Derivation of the mathematical model

of the sensor system can be found in Appendix B.


Raw Data
4 3 5 4 9 5 1 4




3 3 4 4 1 1
SortedData 4 4 5 5 5 4

5 5 9 9 9 5



Filtered Data
Figure 2-9: Median filter example









To account for noise in the infrared detection signals, the first derivative data is

filtered using a three element median filter before the second derivative is calculated.

Median filtering is a non-linear filtering technique useful for the suppression of impulse

noise and the smoothing of edges. It works by taking a set number of data points and

determining the mathematical median of them, which then replaces the data point. An

example of a three element median filter is shown in Figure 2-9. In this example, three

elements of the raw data are grouped together and sorted from low to high. In this

configuration, the median of the data is simply the middle of the three numbers, which is

now the filtered data point [12].

The impulses in the second derivative data represent inflection points on the stairs;

the interior concave stair corer will yield a positive impulse while an exterior convex

stair corner will yield a negative impulse. The system accounts for the stairs that the

Andros has passed by detecting these impulses; if the impulse that is less than a given

threshold value, a stair is counted. The direction of travel upon the stairs, and therefore

whether to add or subtract a stair to the total number counted, is determined by which

sensor detected the impulse first. If the front detector senses the impulse before the rear,

then a stair is added. If the rear detector senses the impulse before the front, then a stair

is subtracted from the total.

The computation of the first and second derivatives of the stair representation and the

application of the median filter induces a delay in the detection of the stair inflections.

Each of the derivative computations account for a one-cycle delay, while the median

filter accounts for a three-cycle delay for a total delay of five cycles. As the detectors are










polled at a rate of 20 Hz, the total delay time is 0.25 seconds between acquisition of the

stair data and detection of a stair inflection.

The stair counter assembly also has an "end of world" capability, meaning that it can

be used for detection of drop-offs and ledges. The system uses this function to determine

the edge of a landing when descending a set of stairs. The edge is detected by monitoring

the output of the infrared sensors: the distances measured will remain constant until the

sensor reaches a point when it is directly over the first step. At this point, there will be a

drastic change in the measured distance, which the system interprets as the edge of the

landing and the beginning of the stairs.



1500



DWT
Andros /1 n
/ \ // Sensor
Chassis \--o
Sensor
Cable



-- - 650



Auxiliary
Track .
\ T- \ _Auxiliary
S/ Track
Assembly



00
Figure 2-10: Auxiliary track position system setup

2.3.2 Auxiliary Track Positioning System

A Draw-Wire Transducer (DWT) sensor, manufactured by UniMeasure, is used to

measure the angle of the Andros auxiliary tracks, one each for the front and rear tracks.









This sensor was used over other forms of angular sensors, such as rotary or optical

encoders, because of its ease of setup and robust mechanical interface; there are no gears

to become jammed with dirt or optical sensors to become inoperable because of grime.

The DWT is simply a spring-loaded potentiometer connected to a three-foot long cable.

The DWT sensor is attached to the chassis of the Andros, with the draw cable being

wrapped around the auxiliary track drum once and then attached to it via a 10-32 cap-

head screw. The setup is shown in Figure 2-10.

A 5-volt reference voltage is applied to the sensor, which will return from 0 to 5 volts

proportional to the length of cable drawn from the sensor. The governing equation for

the angle measured by the system is given in Equation 2-1, where Vhigh and Viow are the

upper and lower voltage bounds observed by the sensor and Vmeasured is the sensor

voltage.


measured l- ow / ^o0
0 m(ee Kow 1500 }(2-1)
high low)

The DWT sensors are interfaced by the RabbitCore microcontroller through the use

of a TLC545 Texas Instruments analog-to-digital converter.

2.3.3 JAUS Positioning System

As there is no GPS being used on the Andros system, the position system is

comprised solely of a PNI Corporation TCM2-20 tilt-compensated module to update the

Andros heading. The compass heading of the Andros is filtered using a three element

median filter, as previously described.

The TCM2-20 is based upon PNI Corp.'s proprietary triaxial magnetometer system

and its biaxial electrolytic inclinometer. When level, it is accurate to within +/- 0.5









degrees RMS with 0.1-degree resolution. This changes to +/- 1 degree RMS when the

system is on an incline. It communicates via a 38.6 kBaud, RS-232 serial connection and

is set to run at a sampling rate of 20 Hz.

The digital compass experiences a computation delay, much in the same manner as

the stair counter system. The three element median filtering produces a delay of three

cycles, which corresponds to a delay of 0.15 seconds between acquisition of the heading

data and realization of the filtered heading.

2.4 Operator Control Unit

In order for the Andros' JAUS control system to be fully operable, an Operator

Control Unit (OCU) was developed on a Gateway Solo 3350 laptop with the Linux

Redhat 8.0 operating system. A Netgear ME102 Wireless Access Point is used to

establish a wireless Ethernet connection with the Andros JAUS controller. The access

point uses the IEEE 802.1 lb standard and transmits up to 11 Mpbs at 2.4 to 2.5 GHz.

To be able to communicate with the JAUS components located on the Andros

platform, the OCU needed to have information pertinent to the construction of the JAUS

messages required to command these components available. Therefore, JAUS message

libraries for the Primitive Driver and Position System components were coded for the

Linux operating system. These libraries were adapted from code obtained from Dr. Jeff

Wit of Wintech, Inc. Communicator and Node Manager components were also coded for

the Linux operating system to allow the OCU to interact with the Andros' JAUS

components. All of the OCU components were developed in parallel with the

corresponding components used on the Rabbit microcontroller.

The OCU console was developed using the Linux Curses library. This was chosen

for the basis of the user interface because it allows for the easy manipulation of the






23


terminal display regardless of the terminal type used. The Curses library only supports

the use of single byte characters for display, but this was more than adequate to meet the

needs of this OCU.















CHAPTER 3
INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION

This chapter defines the Intelligent Primitive Driver (IPD) in terms of the JAUS

architecture. It then details the application of the Intelligent Primitive Driver to the

Andros system.

3.1 Component Definition

For the IPD to be considered a JAUS component, it needs to fit into the rigid

framework that comprises the architecture. Therefore, the component will be defined as

per the specifications detailed in the JAUS Reference Architecture: the component

function, input and output messages, and description will be defined. The component has

been assigned the component identification number of 99 [10].

3.1.1 Component Function

The Intelligent Primitive Driver component is responsible for the control of all

indirect motion related actuators. An indirect motion related actuator is any actuator that

affects the ability of a platform to perform a commanded motion, but does not perform

that motion itself. For example, on the Andros robot, the front and rear auxiliary tracks

are considered indirect motion actuators. They are responsible for aiding the Andros in

moving over rough and uneven terrain, but do not directly produce the motion.

3.1.2 Component I/O

The IPD will accept any of the JAUS core input and output messages, as well as the

"Set Wrench Effort" and "Query Global Pose" commands. These commands are as









defined in Appendix A. Table 3-1 shows the user defined set of input and output

messages and their corresponding unique command codes. The input and output

command sets will be completely defined in the "Input and Output Commands" section

later in this chapter.



Table 3-1: User defined input and output JAUS commands
Command Code Description
OxlFF1 Set Auxiliary Actuator
OxlFF2 OxlFF9 Set Behavior X
O x3FF1 Query Auxiliary Actuator
Ox3FF2 Ox3FF9 Query Behavior X
" Ox5FF Report Auxiliary Actuators
O Ox5FF2 Ox5FF9 Report Behavior X


3.1.3 Component Description

The IPD defines a command interface to control any available indirect motion

actuators available upon a platform and any subsequent set of vehicle behaviors that

would utilize these actuators. Further, the IPD is able to issue wrench commands to a

primitive driver component. Automation of vehicle behaviors is accomplished to ease

operator burden when the JAUS system is acting in tele-operational mode and to decrease

high-level processor load when the system is acting in full-autonomous mode. Similar to

the Primitive Driver component, the IPD does not imply any specific platform in its

definition and therefore is not completely defined until it has been applied to the control

system of a particular platform.

Figure 3-1 illustrates the most basic implementation of the Intelligent Primitive

Driver into the JAUS system architecture. The System Commander may send

commanded wrench efforts to the primitive driver to initiate vehicle motion or any of the









aforementioned IPD command codes to the Intelligent Primitive Driver either to control

an indirect motion actuator or start a vehicle behavior. If a command is sent to begin a

vehicle behavior, the IPD is able to send vehicle specific commands directly to the

vehicle to control the indirect motion actuators. Also, if vehicle motion is necessary to

accomplish the behavior, the IPD may send commanded wrench efforts to the primitive

driver component to incite vehicle motion.

System


System Commander



Commanded
Comade LIPD Command
Wrench Effort

Subsystem
C n CCommanded Q
Wrench Intelligent Pose
Primitive Effort Primitive se Pose
Driver -System
Driver Poseem
Data
Vehicle
Specific Indirect Motion
Actuator Actuator
Commands Commands

-* -

.. 'f'.^ -n tt


Figure 3-1: Intelligent Primitive Driver implementation









3.1.4 IPD Input and Output Messages

This section will define the set of user-defined input and output messages used by the

IPD.

3.1.4.1 "Set Auxiliary Actuators"

The "Set Auxiliary Actuators" message controls the indirect motion actuators

available on the platform. The command consists of four available linear actuator fields

and four available rotational actuator fields. Each field in the command may be mapped

directly to a single actuator of corresponding type, either linear or rotational, for control.

The interpretation of the numerical limits of the data fields allow for a wide array of

actuator control. The limits may be interpreted as a percentage of the maximum speed to

move the actuator at, a percentage of the maximum distance to move the actuator to, or

even interpreted as a blind forward/reverse/stop control message. The data fields and

vector-mapping table is for this command is found in Table 3-2.



Table 3-2: "Set Auxiliary Actuators" command fields
Field # Name Type Units Interpretation
See Mapping Table that
1 Presence Vector Unsigned Short N/A Follows
2 Aux Actuator 1 Scaled Integer
3 Aux Actuator 2 Short Integer Percent Lower Limit: -100
4 Aux Actuator 3 Upper Limit: 100
5 Aux Actuator 4
6 Aux Actuator 5 Scaled Integer
7 Aux Actuator 6 Short Integer Radians Lower Limit: -n
8 Aux Actuator 7 Upper Limit: 7t
9 Aux Actuator 8

Vector to Data Field Mapping for Presence Vector of Above Command
Vector Bit 7 6 5 4 3 2 1 0
Data Field 9 8 7 6 5 4 3 2









3.1.4.2 "Query Auxiliary Actuators"

The "Query Auxiliary Actuators" message will cause the IPD to reply to the

requesting component with a "Report Auxiliary Actuators" message. The command field

is shown in Table 3-3.



Table 3-3: "Query Auxiliary Actuators" command field
Field # Name Type Units Interpretation
See "Report Auxiliary Actuator"
1 Presence Vector Unsigned Short N/A Message


3.1.4.3 "Report Auxiliary Actuators"

The "Report Auxiliary Actuators" command message provides the receiving

component with the current values of the commanded "Set Auxiliary Actuators"

message. The message data and mapping of the presence vector for the "Report

Auxiliary Actuators" message are the same as the "Set Auxiliary Actuators" message, as

seen in Table 3-2.

3.1.4.4 "Set Behavior X"

The "Set Behavior X" message is used to initiate the behavioral control algorithms,

which are to be applied to the individual platform. The message has been issued the

command code range of OxFFF2 to OxFFF9 to allow for 8 vehicle specific behavior codes

to be applied to the control system. The corresponding behavior number, from 1 to 8,

replaces the 'X' in the command code names in the code definition. The data fields are

delineated into 4 unsigned integers and 4 full integers, giving the design engineer a wide

range of available variables to transmit any necessary behavioral data to the system, such

as latitude and longitude, heading, or distance to travel. As such, a specific behavior may









be defined by all, some, or none of the available data fields. The data fields and vector-

mapping table is for this command is found in Table 3-4.


Table 3-4:


"Set Behavior X" command fields


Field # Name Type Units Interpretation
See Mapping Table that
1 Presence Vector Unsigned Short N/A Follows
2 Behavioral Parameter 1
3 Behavioral Parameter 2 Unsigned Int N/A User defined fields
4 Behavioral Parameter 3
5 Behavioral Parameter 4
6 Behavioral Parameter 5
7 Behavioral Parameter 6 Float N/A User defined fields
8 Behavioral Parameter 7
9 Behavioral Parameter 8

Vector to Data Field Mapping for Presence Vector of Above Command
Vector Bit 7 6 5 4 3 2 1 0
Data Field 9 8 7 6 5 4 3 2


3.1.4.5 "Query Behavior X"

The "Query Behavior X" message will cause the IPD to reply to the requesting

component with a "Report Behavior X" message. The command field is shown in Table

3-5.


Table 3-5: "Query Behavior X" command field


Field # Name Type Units Interpretation
See "Report Behavior X"
1 Presence Vector Unsigned Short N/A Message


3.1.4.6 "Report Behavior X"

The "Report Behavior X" command message provides the receiving component with

the current behavioral data being performed by the platform. The message data and









mapping of the presence vector for the "Report Behavior X" messages are the same as

the "Set Behavior X" message, as seen in Table 3-4.

3.2 Intelligent Primitive Driver Application

An Intelligent Primitive Driver component must be applied to a vehicle to fully define

the functionality of the behavioral and auxiliary actuator controls as no vehicle specific

data is given in the JAUS definition of the component. This section will discuss the four

main areas that comprise the application of the IPD to the Remotec Andros test platform.

These areas include: a discussion of the basis of the intelligence used in the control

algorithms, the functionality of the component as it pertains to the Andros robot, an

explanation of the program logic used in the controller, and an explanation of the stair

motion algorithms used by the controller.

3.2.1 Fuzzy Logic

Professor Lotfi Zadeh at the University of California in Berkley developed fuzzy

Logic in 1965 as a method of processing data by allowing partial set membership rather

than classical precise set membership or non-membership. Fuzzy Logic is based upon a

human intelligence model; Professor Zadeh reasoned that people do not need precise,

numerical information as input and yet they are capable of highly adaptive control. As

intuitive as this approach of control may appear, it was not applied to an actual control

system until the 1970's, mainly due to inadequacies in small-computer capabilities at the

time [13].

Fuzzy Logic provides a simple way to arrive at a definite conclusion based upon

vague, ambiguous, noisy or imprecise information. The logic model focuses on what a

system should do rather than trying to understand how the system works and concentrates

on the problem rather than attempting to represent the system mathematically, which may









be impossible, especially in the case of nonlinear systems. Fuzzy Logic incorporates a

simple, rule-based "if X and Y then Z" problem solving control approach. This approach

relies upon an empirically based model, which is dependent on the design engineer's

control experience. The system is inherently robust as it does not require precise inputs,

can be designed to fail safely if an input is lost, and despite the possible wide variation of

the input signal, the output is always a smooth control signal. As the design engineer

defines the rules that govern the system, the controller can easily be modified to improve

or dramatically alter system performance. Finally, any sensor that presents the controller

with an indication of the system's actions, regardless of sensor cost or precision, is a

viable candidate for the fuzzy controller [13].

The fuzzy logic control model was applied to the four major intelligence functions of

the control system: the stair protocol arbiter, the platform alignment controller, the

auxiliary track controller, and the task used to realign the Andros upon the stairs after a

slippage error has occurred. Each of these functions will be discussed as they are

encountered in the descriptions of the control algorithms to follow.

3.2.2 Functionality

To utilize the control capabilities of the Intelligent Primitive Driver, the command

messages associated with the component must be completely defined to interact with the

platform. The "Set Auxiliary Actuators" command must be mapped to control the

platform's indirect motion actuators. Vehicle behaviors must be assigned a control

number corresponding to one of the available "Set Behavior" commands, the requisite

control data for the behavior must be defined and assigned to the proper command

variable and the behavioral algorithms themselves must be characterized and coded for

use.









As shown in Table 3-2, the "Set Auxiliary Actuators" command message has eight

assignable auxiliary actuators command fields. Following this convention, the front

auxiliary track of the Andros robot is denoted as "Aux Actuator 5" and the rear auxiliary

track is denoted as "Aux Actuator 6." These fields were chosen as the auxiliary tracks of

the Andros may be moved to a specific angle through the use of the Auxiliary Track

Position System, described in Chapter 2.3.

The behavioral controls of the IPD are used to control the motion of the Andros on a

set of stairs, both ascending and descending. The ascending motion behavior has been

mapped to "Set Behavior 1" with the descending motion mapped to "Set Behavior 2."

Both behaviors use the same the control data variables, which have been assigned to the

data fields shown in Table 3-6.



Table 3-6: "Set Behavior" 1 and 2 control data
Field # Name Description
2 Behavioral Parameter 1 Rise of a Single Step (in.)
3 Behavioral Parameter 2 Run of a Single Step (in.)
4 Behavioral Parameter 3 Total Number of Steps
5 Behavioral Parameter 4 Not Used
6 Behavioral Parameter 5 Stair Heading (degrees)
7 Behavioral Parameter 6 Not Used
8 Behavioral Parameter 7 Not Used
9 Behavioral Parameter 8 Not Used


3.2.3 Program Logic

Figure 3-2 depicts the logic flow diagram of the Intelligent Primitive Driver upon

startup. This diagram is only representative of the Intelligent Primitive Driver and not

the JAUS system on the whole. The receipt and execution of JAUS commands by

standard components have been omitted because, for these instances, the controller









behaves in a manner consistent with a standard JAUS controller. Upon startup of the

Andros controller, the IPD enters a "ready" state and awaits the reception of an IPD

command message. The receipt of one of these commands causes the IPD to assume

control of the Andros and execute the desired commanded function.


Start Controller



Ready State



Command No
sg Recv'd?

Yes


Execute
Command




Command\ No
Completed?

Yes

Figure 3-2: Intelligent Primitive Driver logic flow diagram

Upon receipt of a "Set Auxiliary Actuators" command, the IPD moves into the

algorithm as shown in Figure 3-3. The IPD uses the Auxiliary Track Positioning System,

as outlined in Chapter 2.3, to determine the current angle of the auxiliary track. Once the

current angle has been determined, the algorithm checks to see in which of three possible

fuzzy sets the current track angle lies: less than the desired angle, greater than the desired

angle, or around the desired angle. The IPD will determine the direction, if any, to rotate

the track dependent upon which set the current track angle lies. If the current track angle









is less than the desired track angle, the track is rotated counterclockwise. If the current

track angle is greater than the desired track angle, the track is rotated clockwise. If the

track angle is equal to the desired track angle, within an angular tolerance of +/-1 degree,

the track is not rotated and the controller IPD returns to the ready state. The two-degree

total tolerance was determined heuristically based upon the maximum update rate of the

controller, the precision of the Auxiliary Track Positioning System and the overall speed

of motion of the auxiliary tracks while rotating. This algorithm is followed independent

of which auxiliary track is commanded to move.


Figure 3-3: "Set Auxiliary Actuator" algorithm









Upon receipt of a "Set Behavior" command, the IPD executes the algorithm shown in

Figure 3-4. The IPD calculates the total dimensions of the stairs from the control data

received along with the command, as seen in Table 3-6. Through simple geometric

equations, the IPD determines the total length, L, and pitch angle, P, of the stairs, as seen

in Figure 3-5. Next, the IPD aligns the heading of the Andros platform with the heading

of the staircase.


Figure 3-4: Opening sequence of "Set Behavior X" algorithm









The align platform function is another of the fuzzy logic functions. It calculates the

difference between the reported stair heading and the current heading of the Andros,

obtained from the Andros' onboard digital compass. The absolute value of the difference

is then compared against the defined fuzzy sets.







Total Length

Total Rise

Run -


Rise

Total Run
Figure 3-5: Stair data representation

If the absolute value is greater than 90 degrees, the Andros is rotated at its maximum

speed. If the absolute value is between 90 and 60 degrees of error, the Andros is rotated

at 75% of its maximum speed. If the absolute value is between 60 and 25 degree of error,

the Andros is rotated at 50% of its maximum speed. Finally, if the absolute value is less

than 25 degrees, the Andros is rotated at 25% of its maximum speed. This function has

an allowable angular tolerance of +/-4 degrees. The direction of the commanded rotation

is also dependent upon a fuzzy interpretation of the angular difference. If the absolute

value of the difference is less than 180 degrees and the actual difference is negative, the

Andros is rotated counterclockwise at the desired speed. If the absolute value of the

difference is less than 180 degrees and the actual difference is positive, the Andros is

rotated clockwise at the desired speed. The direction of rotation relative to the actual









value of the difference is reversed if the absolute value of the difference is found to be

greater than 180 degrees. This ensures that the Andros takes the shortest route possible to

reach the commanded heading.

Once the Andros has been aligned, the IPD starts the skew alignment task. This is a

separate program thread, which runs parallel to the main stair control thread. The

purpose of the skew alignment task is to detect and counter any angular slippage of the

Andros upon the staircase. Slip detection is accomplished by monitoring the difference

between the current heading of the Andros and the heading of the stairs, similar to the

align platform function.



Direction of Slip














Direction of
Adjustment

Figure 3-6: Skew alignment task correction

If an angular slippage error is detected, the skew alignment task counters it by

rotating the Andros in the direction opposite of the slippage. (Figure 3-6) This, again, is

a fuzzy logic task as the slippage error is grouped into broad sets of possible angular

error. If the error is greater than 5 degrees but less than 10, the Andros is rotated at 15%









of its maximum speed. If the error is between 10 and 25 degrees, the Andros is rotated at

25% of its maximum speed. At greater than 25 degrees, the error begins to approach a

non-recoverable state, and the Andros is stopped so that appropriate measures can be

taken to safely move it off of the staircase. Once the heading error is less than the 6

degrees of angular tolerance, the Andros rotation is halted. The linear motion control

command of the Andros is never affected by the skew alignment task, except for the case

in which the error is greater than 25 degrees, as the Andros' embedded controller allows

for both linear and rotational motion components to be commanded at the same time.

After the skew alignment task has been spawned, the IPD begins the stair counter

task. The stair counter task uses the stair counter assembly, as described in chapter 2.3,

to count the number of steps the Andros has successfully passed and also to account for

any possible linear slippage error. The number of steps must be counted to provide the

IPD with the relative position of the Andros upon the staircase to trigger stair motion

events, such as auxiliary track motions.

The next step for the IPD to complete is to determine which stair protocol should be

evoked. This is accomplished by determining if the total length, L, of the staircase is less

than or greater than the critical length. The critical length is defined as 1.5 times the total

length of the Andros. If the total length is less than the critical length, protocol 1 is

chosen. If the total length is greater than the critical length, protocol 2 is chosen. The

reason for the demarcation between the two protocols is simple: a staircase with a total

length equal to or less than the critical length simply does not have enough available

length to adequately carry out the full range of stair climbing motions. Also, the majority

of the stair motions are meant to ensure that the Andros is stable upon the staircase and









that the tracks do not lose traction. This is not a concern on short staircases as it is on

longer ones.

It should be noted that the portion of the stair motion algorithm, as seen in Figure 3-4,

is the same for both the ascend and the descend behavior commands. Also independent

of the direction of travel upon the stairs is the protocol arbiter. Protocol 1 is designated

for control of the Andros on a set of stairs less than the critical length in both the ascend

and descend commands, protocol 2 corresponds to control of the Andros on a set of stairs

longer than the critical length in both the ascend and descend commands.

Once the stair protocol has been carried out, the controller reverts back to its ready

state and awaits further commands from the System Commander.

3.2.4 Ascend Protocol 1

This stair motion protocol deals with the situation in which the total length of the

staircase is less than the critical length. First, the front auxiliary tracks of the Andros are

aligned with the angle of the stairs, P. (Figure 3-7a) Then, the Andros is simply started

up the staircase. The protocol concludes as the Andros passes the last step of the

staircase and is safely situated on the top landing, as seen in Figure 3-7c.

3.2.5 Ascend Protocol 2

The second ascend stair motion protocol deals with the situation where the total

length of the staircase is longer than the critical length. In this situation, the full range of

control steps are necessary to ensure that the Andros makes it safely to the top of the

staircase. The first stage of the process is to align the front auxiliary tracks of the Andros

with the angle of the stairs, 0, and the rear auxiliary tracks parallel to the ground. (Figure

3-7a) This stage occurs while the Andros is preparing to climb the staircase, therefore








there are no steps associated with it. In the next stage, the Andros is started up the

staircase. After two steps have passed, the front auxiliary tracks are aligned parallel with

the line of the stairs, as seen in Figure 3-7b. The Andros continues on in this third stage

alignment until the last step of the staircase is reached. As this step is reached, the last

stage is initiated. The front auxiliary tracks of the Andros are moved downward to catch

the Andros as it passes the apex of the stairs. This can be seen in Figure 3-7c.





a)



2 f

c;3 T r


Figure 3-7: Ascend stair motion protocol: a) Align front auxiliary tracks with stair
angle; b) Andros moving on stairs; c) Andros moving over apex of stairs


r\/rd









3.2.6 Descend Protocol 1

As with ascend protocol 1, descend protocol 1 is evoked when the total length of the

staircase to be traversed is less than the critical length. The Andros is moved to the edge

of the staircase and the front auxiliary tracks are moved downward to catch the Andros as

it crosses the apex of the stairs, as seen in Figure 3-8a. Next, the Andros is simply driven

over the edge of the steps and the front auxiliary tracks are moved parallel to the ground

plane. Once the Andros has reached the floor level, it is moved away from the staircase.


Figure 3-8: Descend stair motion protocol: a) front auxiliary track moved to catch
Andros; b) rear auxiliary track moved to push Andros over apex; c) align
front auxiliary track with stairs; d) front auxiliary tracks moved to catch
Andros at stair landing









3.2.7 Descend Protocol 2

Descend protocol 2 occurs when the total length of the staircase to be traversed down

is longer than the critical length. The Andros is moved to the edge of the stairs and the

front auxiliary tracks are moved downward to catch the Andros as it crosses the apex of

the stairs. (Figure 3-8a) While this is occurring, the rear auxiliary tracks are moved

downward to help rotate the Andros down to the plane of the staircase. (Figure 3-8b) The

Andros is moved forward until the main tracks come in contact with the stairs, as seen in

Figure 3-8c. The controller uses the "end of world" capability of the stair counter

assembly to determine the edge of the stairs, as discussed in Chapter 2.3. The Andros is

moved further forward and rear auxiliary tracks are moved to a horizontal position. The

Andros is moved down the steps until the third to last step is reached. Then, the front

auxiliary tracks are moved to parallel to the ground plane, which allows the Andros to

make an easy transition to the plane of the floor. (Figure 3-8d) The Andros is then

moved off and away from the staircase.















CHAPTER 4
TESTING AND RESULTS

This chapter describes the testing of the individual subsystems associated with the

Andros' Intelligent Primitive Driver (IPD). Testing procedures and results will be

reported for the stair-counter assembly, the auxiliary track positioning system and the

heading alignment controller.

4.1 Stair-Counter Assembly

4.1.1 Testing Procedure

The stair counter assembly was tested to ascertain whether or not the concept would

accurately count the number of stairs the platform has passed and therefore, be a viable

addition to the positioning system. The first step to accomplish this task was to calibrate

the infrared sensors that the system uses. This was done to correlate the values returned

from the analog-to-digital converter (ADC), which are used to interface the Sharp

GP2D12 infrared object detectors and the Rabbit RCM3200 microcontroller, to their

corresponding distances. To do this, a target was first placed a known distance away

from the infrared sensor. Then, one hundred readings of the value returned from the

infrared sensor through the ADC were recorded and their average obtained. The target

was then moved to another known distance and the average value was again found. This

process was repeated for distances measuring 4, 6, 8, 10, 12, 14 inches. The data points

were plotted using Excel and several regression curves were applied to determine which

type best fit the data. It was determined that the non-linear power function shown in










Figure 4-1 best described the output. The equation shown was then used in the code to

convert the ADC readings to distances for the testing.


SR' =0.9974

80


60


40


20


0
0 2 4 6 8 10 12 14
Distance (in)

Figure 4-1: Calibration data for Sharp GP2D12 infrared object detectors

Once the infrared sensor had been calibrated, a method of gathering the test data from

the staircase needed to be devised. To accomplish this, a testing frame made from 80/20

extruded aluminum framing system was constructed. The 80/20 was chosen for this task

as it was easily assembled and the extruded grooves were ideal for constraining the

motion of the test sled along the major axis of the stairs. The test sled housed the Rabbit

microcontroller as well as one of the Sharp GP2D 12 infrared object detectors to acquire

the range data. The sled was then tethered to a 12-volt gear motor to pull it along at a









relatively constant velocity. The entire assembly was placed upon the stairs, as seen in

Figure 4-2.






















Figure 4-2: Stair-counter testing assembly

The system recorded a reading of the range data from the surface of the staircase to

the infrared sensor once every 50 milliseconds. This delay was chosen, as it is longer

than the 32-millisecond update rate of the infrared sensors and therefore ensured that no

duplicate readings were accidentally recorded by the system. The microcontroller then

determined the first derivative of the data, applied a three element median filter to it, and

then determined the second derivative. A Dell Inspiron 8100 laptop computer then

recorded this data set. Communication between the Dell and the Rabbit were made via

the 57.6-kBaud connection provided for diagnostic purposes by the microcontroller. The

test was run a total of ten times on two separate staircases.

The stair-counter testing also had a secondary purpose: to empirically determine a

second derivative threshold value for the stair-counter control code. The stair-counter









code uses the second derivative values to determine if a stair has been passed and should

therefore be counted. However, detecting a single second derivative value for this

purpose is futile; a range of second derivative values that correspond to a stair edge may

be encountered. The system may also experience subtle negative second derivative peaks

due to uneven motion of the Andros upon the stairs. To account for all of this, the second

derivative value is compared to a threshold value. If the value is less than the threshold,

it is determined to be a stair edge and is counted.

4.1.2 Results

The data collected from the stair-counter testing rig was placed into an Excel

spreadsheet for graphing purposes. The data was analyzed to determine when the second

derivative of the stair representation occurred with respect to the recorded inflection

point, or outside edge, of the stairs.

Figure 4-3a illustrates the first set of sample data from the acquired from the testing.

The dark blue line represents the detected outline of the staircase, while the red line

represents the calculated second derivative of this data. Clearly visible are the two large

negative impulses, each one corresponding to one of the stair peaks shown. As designed,

each impulse is logged 0.25 seconds after the stair peak is experienced. The same is true

of Figures 4-3b and 4-3c; each one has two large, negative impulses that occur 0.25

seconds after their corresponding stair peaks are detected. Also, in each of these figures,

the negative impulses are less than -0.2, while none of the tertiary negative impulses

approach this value. Therefore, this was determined to be the optimum threshold value

for the system to use.








47
a) Stair Data Representation and 2nd Derivative Data, Samplel



10 1
9 0.8
8 Dt-0.6
S7 .-_ % 0.4
6 0.2
5- 0



2 Stair Data -0.6
1 e 2nd Derivative -0.8
0 -1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Time (Sec)


b) Stair Data Representation and 2nd Derivative Data, Sample 2



10 1
9 f0.8
8 0.6
7 0.4
6" 0.2
5 0
4- 4-0.2
o 3 Stair Data -0.4
2 2nd Derivative -0.6
1 -0.8
0 -1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Time (sec)


c) Stair Data Representation and 2nd Derivative Data, Sample 3


10 1
9 -- 0.8
8- 0.6
7 W -, 0.4
6 0.2
5 5 a% Wo .

4 -0.2
3 W- O -0.4
2 Stair Data -0.6
1 -0.8
1 2nd Derivative
0 -1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Time (sec)


Figure 4-3: Stair-counter data: a) sample 1, b) sample 2, c) sample 3









4.2 Auxiliary Track Positioning System

4.2.1 Testing Procedure

The setup for the auxiliary track positioning system testing had two steps. First, the

maximum and minimum values returned to the system by the Draw Wire Transducer

(DWT) were obtained. These values are used in conjunction with Equation 2-1 to

convert the measured DWT value to an angular measurement. The maximum value

occurs when the auxiliary track has been rotated to its topmost point, while the minimum

value occurs when the auxiliary track has been rotated to its bottommost point; these

points correspond to 150 degrees and 0 degrees, respectively. At each of these two

points, one hundred values of the DWT were taken and then an average value was

obtained.


Figure 4-4: Plumb compass attached to Andros auxiliary track









The second step in the setup was to affix a plumb compass to the auxiliary track so

that an independent angle measurement of the position of the track could be made. A

plumb compass is comprised of a needle, weighted at the bottom, along with an

adjustable faceplate. By attaching the body of the plumb compass to a structure, the

relative angle of the structure with respect to ground may be found when the structure is

rotated. The Andros auxiliary tracks were rotated to their bottommost point and the

adjustable face of the plumb compass was then adjusted such that the compass needle

pointed to 0 degrees. In this configuration, the compass needle pointed to 150 degrees

when the auxiliary tracks were rotated to their topmost position, which corresponds to the

measurement convention utilized by the controller. Figure 4-4 illustrates the plumb

compass attached to the Andros' auxiliary track.

To test the commands for the auxiliary track positioning system, the Operator Control

Unit (OCU) was used to send the experimental JAUS message, "Set Auxiliary

Actuators," to the Andros' JAUS controller, along with a commanded angular position of

the auxiliary track. The initial set of commanded angles were used to determine the

minimum allowable tolerance that could be used by the system without the system

becoming unstable. In this case, the system would be unstable if the controller

continually reversed the direction of the auxiliary track in an attempt to move the track to

the desired angle and be within the given tolerance. The minimum allowable tolerance

for the system was found to be +/- 1 degree. Following this, another set of "Set Auxiliary

Actuators" commands were sent to the system and the commanded angle, the angle

returned by the DWT sensor, and the angle read off of the plumb compass were recorded.










4.2.2 Results

Figure 4-5 shows a plot of the controller commanded halt angle and the actuator halt

angle versus the commanded angle sent to the controller from the OCU. The controller

commanded halt angle is the angle returned to the controller from the DWT sensor at the

instant that the controller issued the halt rotation command. The actuator halt angle is the

angle read from the plumb compass and corresponds to the angle of the auxiliary track

after the rotation has actually stopped. Both sets of data points have a linear distribution

across the entirety of the available range of motion, as illustrated by the applied trend

lines and their respective R2 values. The controller commanded halt angle and the

actuator halt angle are identical at 0 degrees and 150 degrees because there are physical

stops at these points of rotation on the Andros frame.

150 -
140
130
120
110
100
Sy = 1.0x + 0.4 *
a 90 -
SR = 0.9998
S80
S70 y 1.0.x- 1.6
70 2
S60 R= 0.9921
50
40 Actuator Halt Angle
30 0 Controller Commanded Halt Angle
20 -Actuator Halt Angle
10 Controller Commanded Halt Angle
04
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150
Commanded Angle (Degrees)
Figure 4-5: Controller commanded halt angle and actuator halt angle versus operator
commanded angle













Figure 4-6 depicts a plot of the error between the commanded angle sent from the

OCU and the controller commanded halt error and the actuator halt angle. The controller

commanded halt error is the error between the commanded angle and the auxiliary track

angle at the instant that the controller issued the halt command and is recorded from the

DWT sensor. The actuator halt error is the error between the commanded angle and the

auxiliary track angle after the track actually stops and is recorded from the plumb

compass. The average error value returned from the DWT sensor is 0.5 degrees with a

standard deviation of 0.3, whereas the average error value returned from the plumb

compass is 3.4 degrees with a standard deviation of 2.2.


9.U
8.0
7.0
6.0
5.0

5.0 -*
4.0

3.0
' 2.0
1.0










-0.0
.o Q 10 0 60 ^ 80 90 100 110 120 130 140



-5.0



-6.0- Controller Commanded Halt Angle Error
-7.0--
Actuator Halt Angle Error
-8.0--
-9.0

Commanded Angle (Degrees)
Figure 4-6: Controller commanded halt error and actuator halt error versus operator
commanded angle









4.3 Heading Alignment Controller

4.3.1 Testing Procedure

The first step necessary to test the heading alignment controller was to calibrate the

PNI Corporation TCM2-20 digital compass. A serial connection was established

between the digital compass and a Dell Inspiron 8100 laptop computer and the digital

compass was placed into polling mode. Then, the compass was given the command to

start its calibration cycle and the Andros was slowly rotated in a circle for approximately

four minutes. Once this was completed, a series of "Set Behavior 1" commands were

sent from the OCU to the Andros JAUS controller, along with the desired heading. The

JAUS controller was coded such that the "Set Behavior 1" command initiated the heading

alignment code. The first series of tests were administered to determine the minimum

allowable tolerance value that the system could accept without the system becoming

unstable. In this situation, the system would be unstable if the controller continually

reversed the rotation of the Andros in an attempt to move the Andros to the desired

heading. From these initial tests, the allowable tolerance for the system was found to be

+/- 4 degrees. After this was completed, another set of "Set Behavior 1" commands were

sent from the OCU and the commanded heading, compass heading, and final Andros

heading were recorded. The compass heading is the value that the digital compass last

reported to the controller to illicit a stop rotation command. The final Andros heading is

the compass measure of the heading of the Andros when the rotation actually stops.

4.3.2 Results

Figure 4-7 depicts a plot of the controller commanded halt heading and the vehicle

halt heading versus the desired heading sent from the OCU. The controller commanded

halt heading is the heading returned to the controller at the instant that the controller










issues a stop vehicle rotation command. The vehicle halt heading is the heading of the

vehicle when the vehicle actually stopped its rotation. Both sets of data have a linear

distribution across the entire range of rotation, as illustrated by the applied trend lines and

their respective R2 values.


360
340
320
300
280
260
24 240
^ 220
0 y = 0.9x + 2.2
200
180 R = 0.9992
160
e 140
Z 120
100 Vehicle Halt Heading

80 W Controller Commanded Heading
60
SVehicle Halt Heading
40
420 y= 1.Ox 3.2 Controller Commanded Heading
20
0 ...... ... 0.R 60.9 67 .
0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360
Desired Heading (Degrees)
Figure 4-7: Controller commanded halt heading and vehicle halt heading versus
operator commanded heading

Figure 4-8 depicts a plot of the controller commanded heading error and the vehicle

heading error versus the desired heading sent from the OCU. The controller commanded

heading error is the error between the desired heading and the heading of the vehicle

when the controller issues a stop rotation command. The vehicle heading error is the

error between the desired heading and the heading of the vehicle when its rotation is

actually stopped. The average error value for the controller heading is 2.8 degrees with a







54


standard deviation of 0.8, whereas the average error value for the final Andros heading is

5.9 degrees with a standard deviation of 1.7.


10
9
8


6 -


4 -


2
1
0
-1 60 120 180 240 300 3i0
-2 0
-3 -
-4
-5
-6
-7 -
Vehicle Heading Error
-8
-9 4 Controller Commanded Heading Error
-10

Heading (Degrees)
Figure 4-8: Controller commanded heading error and vehicle heading error versus
operator commanded heading















CHAPTER 5
CONCLUSIONS AND FUTURE WORK

5.1 Conclusions

This research focused on the development of the Intelligent Primitive Driver (IPD),

an experimental, low-level, intelligence component for the Joint Architecture for

Unmanned Systems (JAUS). Three objectives were necessary to accomplish this task.

First, the IPD had to meet the criteria of a fully defined, standard JAUS component.

Second, a testing platform had to made JAUS compliant and the functionality of the IPD

had to be applied to the testing platform. Finally, the intelligence components of the IPD

that were applied to the testing platform had to be tested.

A standard JAUS component is defined through four criteria: the function of the

component, the accepted input and output messages that the component may handle, and

the full description of the component. In these terms, the IPD was fully constrained to

the JAUS architecture. The purpose was defined as being responsible for the control of

all indirect motion related actuators. A full set of input and output messages were

defined to meet the JAUS message standards. The component description defined the

implementation of the IPD into the JAUS architecture, set the IPD's unique component

identification number at 99, and discussed the specifics of the IPD's functionality.

A Remotec Andros robot was chosen as the testing platform because of the indirect

motion actuators located on the chassis and its complicated behavioral controls, namely

stair-climbing. A complete JAUS controller was developed specifically to be used by the









Andros platform; an Operator Control Unit (OCU), Primitive Driver, Node Manager,

Position System and Communicator components were coded for both the Rabbit

RCM3200 microcontroller with the Dynamic C operating system and the Gateway Solo

3350 laptop with the Linux Redhat 8.0 operating system. The Rabbit was used as the

Andros' JAUS controller, while the Solo 3350 was used as the OCU. The Intelligent

Primitive Driver was applied to the Andros platform: the IPD's capability to control

indirect motion actuators were mapped to the auxiliary tracks of the Andros and the

behavioral control commands were mapped to the stair ascending and descending

procedures. The proprietary Andros control stream was reverse engineered from the

native Andros controller and then applied to the Primitive Driver and Intelligent Primitive

Driver. As such, the Andros' JAUS controller was able to accept and interpret JAUS

commands and incite the Andros to act upon these commands accordingly. The

controller, as mounted on the Andros platform, can be seen in Figure 5-1.


Figure 5-1: Controller mounted on Andros platform









The intelligence components of the Intelligent Primitive Driver were tested to ensure

that they adequately performed the desired control function. A testing frame was

constructed to constrain the motion of a sled housing one of the Sharp GP2D 12 infrared

object detectors so that the stair-counter assembly could be tested. From the data

gathered from the system, it was shown that the negative second derivative impulses

could be observed by the system and that they did indeed lag the detection of the outside

stair edge by 0.25 seconds, as designed. The auxiliary track positioning system was

tested to determine if the final angular placement of the auxiliary tracks coincided with

the desired angular command. It was found that the average error value for the controller

commanded halt angle was 0.5 degrees with a standard deviation of 0.3, whereas the

average error value for the actual auxiliary actuator position was 3.4 degrees with a

standard deviation of 2.2. The minimum allowable tolerance for this control system was

+/- 1 degree. The heading alignment controller was tested to determine if the final

heading of the Andros coincided with the desired heading command. It was found that

the average error value for the controller commanded halt heading was 2.8 degrees with a

standard deviation of 0.8, whereas the average error value for the actual halt heading of

the Andros was 5.9 degrees with a standard deviation of 1.7. The minimum allowable

tolerance for this control system was +/- 4 degrees. Both of these control systems

performed as designed and returned favorable data when the limitations inherent to the

Andros platform were taken into account.

The discrepancies between the DWT and plumb compass error in the auxiliary track

positioning system and the final heading and compass heading error in the heading

alignment controller are a direct manifestation of the limitations of the Andros system.









As discussed in Chapter 2, the maximum update rate of the Andros control stream is 5

Hz. In terms of autonomous computer controllers, 0.2 seconds is a relatively long

amount of time. In both the auxiliary track positioning system and the heading alignment

controller tests, the controller commanded a halt of system motion that was not acted

upon until at least 0.2 seconds later. This fact translated into an average difference of 2.9

degrees for the auxiliary track positioning system and an average difference of 3.1

degrees for the heading alignment controller. Therefore, when the controller believes it

has reached the desired command position and has thus stopped the motion of the

Andros, the Andros is in actuality continuing to move. It is for this reason that the

Andros stair motion behavior has been broken down into its component parts and these

parts have been tested individually, instead of simply testing the Andros stair motion

controller in its entirety; it is entirely within the realm of possibility that the Andros

would incur a non-recoverable, fatal error when attempting to negotiate a staircase even

though the controller recognized the error and attempted to correct it.

The Andros is able to negotiate a set of stairs when controlled by a human operator

with a more reasonable expectation of a successful conclusion than with the JAUS

controller for two reasons, though it is still a very difficult and complicated task. First, in

terms of human control, 0.2 seconds is a relatively long amount of time. Second, the

human operator has both control experience and predicate knowledge of the system.

Therefore, the human operator can make predictive assumptions concerning the stair

motion process that the JAUS controller is unable to make. For example, the human

operator can take into account the type of stair to be traveled upon, the condition of the

Andros' tracks, and the amount of traction that the Andros is exhibiting when actually on









the stairs to make corrections to the stair motion process. With this incarnation of the

IPD, these predictive capabilities are not present.

5.2 Future Work

To increase the controllability of the Andros-IPD system, upgrades need to be made

to several of the subsystems. First, and most importantly, the Andros embedded

controller should be updated to a more modern control scheme. The outdated controller

and its 1200-Baud connection should be replaced by a modern microcontroller utilizing a

secure Ethernet connection protocol, such as the Transmission Control Protocol (TCP).

This replacement would solve the control problems, which currently inhibit the system.

When making this update, the current drive motors and auxiliary track positioning motors

should be replaced with motors that have integrated rotary encoders. This would serve

two purposes. First, the encoders located on the driver motors could be utilized to add

dead-reckoning capability to the current position system. With this, specific information

concerning the total movement of each individual track could be collected and used for

more exact vehicle placement. Second, the encoders on the auxiliary track positioning

motors could replace the Draw Wire Transducers (DWT) currently used to acquire

auxiliary track position. The DWT sensors work very well, but are susceptible to

environmental conditions and hazards; the internal encoders would not have this potential

problem. The Intelligent Primitive Driver should be modified to include adaptive control

capabilities to the stair motion algorithms. Concepts of neural networks could be applied

to the controller to give it the ability to learn from stair motion trials. This would allow

the system to adapt the stair motion algorithms to work more efficiently on different

types of stairs. For example, the controller could determine if an auxiliary track should






60


be moved at a different point during the stair motion algorithm or change the correction

speeds used to correct the Andros if it slips on the staircase.

Finally, the Intelligent Primitive Driver should be applied to other JAUS compliant

platforms and further application testing should be performed. In doing this, the viability

of the component could be completely explored and documented. After this, the

component could be presented to the Working Group of the Joint Architecture for

Autonomous Systems (JAUS) for the formal inclusion of the IPD into the Reference

Architecture.


















APPENDIX A
STANDARD JAUS MESSAGES

This Appendix contains information pertaining to the "Set Wrench Effort" and

"Query Global Pose" standard JAUS messages, as well as a list of the core JAUS

message set.

A.1 Query Global Pose

The command code for this message is defined as 0x2402 and causes the receiving

component to respond with a "Report Global Pose" message. Table A-i depicts the data

field assignments for the "Query Global Pose" message [10].



Table A-i: "Query Global Pose" data field (used from JAUS: Reference Architecture
Specification, pg. 93)
Field # Name Type Units Interpretation
Presence Unsigned A See Report Global Pose
Vector Short Message





A.2 Set Wrench Effort

The command code for this message is defined as 0x0405 and controls platform

mobility actuators by mapping the six propulsive and six resistive elements that comprise

a wrench command to the mobility actuators of a vehicle. Table A-2 depicts the data

field assignments for the "Set Wrench Effort" message [10].














Table A-2: "Set Wrench Effort" data fields (from JAUS: Reference Architecture
Specification, pg. 80)
Field # Name Type Units Interpre


1 Presence Vector


2 Propulsive Linear
Effort X
3 Propulsive Linear
Effort Y
Propulsive Linear
Effort Z
5 Propulsive Rotational
Effort X
6 Propulsive Rotational
Effort Y
7 Propulsive Rotational
Effort Z
Resistive Linear
Effort X
Resistive Linear
Effort Y
Resistive Linear
Effort Z
Resistive Rotational
Effort X
Resistive Rotational
12
Effort Y
Resistive Rotational
13fort
Effort Z


Unsigned Short








Short Integer














Byte


N/A








Percent














Percent


See mapping
table that
follows.


Scaled Integer
Lower Limit
=-100
Upper Limit
= 100










Scaled Integer
Lower Limit
=0
Upper Limit
= 100


Vector to Data Field Mapping for Above Command
15 14 13 12 11 10 9
R R R R 13 12 11
7 6 5 4 3 2 1
9 8 7 6 5 4 3
"R" indicates that the bit is reserved.


station


Vector Bit
Data Field
Vector Bit
Data Field


0
2









A.3 JAUS Core Message Set

Table A-3 shows the core set of JAUS messages and their corresponding command

codes [10].


Table A-3: JAUS core message set
Code
Ox01 Set Component A1
0x02 Shutdown
0x03 Standby
0x04 Resume
0x05 Reset
0x06 Set Emergency
0x07 Clear Emergency
0x08 Create Service Co
0x09 Confirm Service C
OxOA Activate Service C
OxOB Suspend Service C
OxOC Terminate Service
OxOD Request Compone
OxOE Release Compone
OxOF Confirm Compon
Ox10 Reject Componenl


Description
authority







nnection
connection
connection
connection
Connection
nt Control
nt Control
ent Control
t Control















APPENDIX B
STAIR COUNTER MATHEMATICAL DEVELOPMENT

The ability to count the number of steps the Andros has passed is critical to the ability

of the Intelligent Primitive Driver to perform its designed task. As discussed in Chapter

3, the current location on the stairs of the Andros is used to trigger controlled events

during the stair climbing procedure. To ensure that this was done as accurately as

possible, the optimum deployment angle for the infrared sensors needed to be determined

so that the stair peaks and their corresponding second derivative impulses were easily

observable by the system.



Y


Sensor Line of Action

offset
/7 I --X


Figure B-l: Stair representation


~ u









The stair representation used for this development has been drawn relative to the

plane of motion of the Andros, as shown in Figure B-1. This reference frame is

appropriate as the sensor array moves along a path parallel to the plane of motion of the

Andros and the measured distances are relative to this plane, and not to the ground plane.

The single stair representation shown is defined by its rise, run, and the angle, P, which is

determined through basic geometry and is constructed of two lines that are perpendicular

to each other at their single point of intersection. As the stair representation is

constructed of two linear equations, one for the rise and one for the run, two separate

equations for the distance, d, must be developed. The distance, d, is the range distance

measured from the infrared sensor to the profile of the stair.


Y





(xo,yo) a (xy)






j-X
"__ _ x


Stair Runner


Figure B-2: Stair runner model


1









Figure B-2 shows the model used for the development of the equation for the

distance, d, as it applies to runner of the stair. The first step in determining d is to find

the point of intersection between the stair runner linear equation and the line of action of

the sensor, (xo, yo). As the y-axis component of this point is constrained to be at yo, xo

can easily be found by solving the equation of the line. Using this as the point of origin,

the distance, a, can be found to the point (x,y), which corresponds to the current location

of the sensor. This distance is given as:

a = (xo x) + (yo y) (B-l)

Now that the distance, a, has been acquired, the perpendicular distance, f, can be found

by the equation:

f = a sinf (B-2)

Through the similar triangles concept, the angle, P, is shown on the two locations of

Figure B-2. The angle, y, is the user-defined angle of the infrared sensor. Therefore, the

intermediate angle, r, may be found, which then leads to the angle, d, by the equation:

0 = 90 7 P (B-3)

The distance, d, is now simply:


Cd O (B-4)


Figure B-3 shows the model used for the development of the equation for the

distance, d, as it applies to riser of the stair. Again, the first step is to find the point of

intersection, (xo, yo), between the stair riser linear equation and the line of action of the

sensor. Again, as the y-axis value is constrained to be yo, xo can be found by solving the






67


equation of the line. Using this as the point of origin, the distance, a, can be found to the

point (x,y), which corresponds to the current location of the sensor.



(x,y) a -


XX
Y




d


SStair Riser



Figure B-3: Stair riser model

The equation for this distance is shown in Equation B-1. Through the similar

triangles concept, the angle, 0, is shown on the two locations of Figure B-3. The angle, y,

is the user-defined angle of the infrared sensor. Using y and 0, the angle, T, may now be

found by:

=r-P (B-5)


The distance, f, is defined as:


f = a cos

Finally, the distance, d, may be found by:


d =
COS Z


(B-6)


(B-7)










The two equations for the distance, d, and the stair data representation were placed

into an Excel spreadsheet for analysis. From this, Figure B-4 was obtained. As shown in

the figure, if the user-defined sensor angle, y, is less than 90 degrees relative to the line of

action of the sensors, the stair edge is skewed to the left and the risers are more

pronounced over the range of the stair data. If y is greater than 90 degrees to the line of

action of the sensors, the stair edge is skewed to the right and the runners are more

pronounced over the range of the stair data. Therefore, it was determined that y should be

90 degrees, or perpendicular to the line of action of the sensors, as this case is neutral and

shows no preference to either the risers or to the runners of the stair data. As the stair

edges are more pronounced in the neutral case, so to will the second derivative impulses

be more pronounced and more easily observed by the system.



18

16

14 -

1200

10

8

6

4

2 *y<90
y= 90
0 -7Y>90
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Distance (in)

Figure B-4: Calculated distances, d, for varying value ofy















LIST OF REFERENCES


[1] Bayouth, M., Nourbakhsh, I., and Thorpe, C., "A Hybrid Human-Computer
Autonomous Vehicle Architecture," Third ECPD International Conference on
Advanced Robotics, Intelligent Automation and Control, 1997.

[2] Mustererkennung und Szenenanalyse (MESA) Research Group, 2003, "Semi-
Autonomous Driving: Intelligent Cruise Control," MESA Research Group,
http://www.neuroinformatik.ruhr-
unibochum.de/PROJECTS/PATREC/projects/DAS/sadicc/sadicc d.html, Feb
2003.

[3] Schlegel, N.,1997, "Autonomous Vehicle Control Using Image Processing,"
Virginia Polytechnic Institute and State University,
http://scholar.lib.vt.edu/theses/public/ etd-283421290973280/etd.pdf, Feb 2003.

[4] Connell, J. and Viola, P., "Cooperative Control of a Semi-Autonomous Mobile
Robot," Proc. of the 1990 IEEE International Conf. on Robotics and Automation
(ICRA-90), 1990, pp. 1118-1121.

[5] Huntsberger, T., and Rose, J., "Behavior-based control for autonomous mobile
robots," ROBOTICS2000, Albuquerque, NM, Mar 2000, pp. 299-305.

[6] Matthies, L., Xiong, Y., Hogg, R., Zhu, D., Rankin, A., Kennedy, B., Hebert, M.,
Maclachlan, R., Won, C., Frost, T., Sukhatme, G., McHenry, M., and Goldberg,
S., "A Portable, Autonomous, Urban Reconnaissance Robot," The 6th
International Conference on Intelligent Autonomous Systems, Venice, Italy, July
2000.

[7] Lewis, M., and Simo', L."Certain Principles of Biomorphic Robots,"
Autonomous Robots, volume 11, 2001, pp. 221-226.

[8] Talebi, S., M. Buehler, M., and Papadopoulos, E., "Towards Dynamic Step
Climbing for a Quadruped Robot with Compliant Legs," Proceedings of the 3rd
International Conference on Climbing and Walking Robots, Madrid, Spain,
October 2000.

[9] Lauria, M., Piguet, Y. and Siegwart, R. "Octopus An Autonomous Wheeled
Climbing Robot," In Proceedings of the Fifth International Conference on
Climbing and Walking Robots. Published by Professional Engineering Publishing
Limited, Bury St Edmunds and London, UK, 2002.






70


[10] JAUS Working Group, 2002, "Joint Architecture for Unmanned Systems (JAUS):
Reference Architecture Specification", Version 3.0, Volume 2, The Joint
Architecture for Unmanned Systems, http://www.jaugs.org, Feb 2003.

[11] Operations and Maintenance Manual for Andros Mark VI Robot System,
Remotec, Inc., Oak Ridge, TN., (2001).

[12] Bock, R., 1998, "The Data Analysis BriefBook: Median Filter,"
Forschungszentrum Juelich, http://ikpell01.ikp.kfa-
juelich.de/briefbook data analysis/nodel68.html, June 2003.

[13] Tanaka, K., An Introduction to Fuzzy Logic for Practical Applications, Springer,
New York, New York, (1997).















BIOGRAPHICAL SKETCH

Peter M. Vinch, Jr. was born on October 29, 1976 in Lawrenceville, New Jersey to

Peter and Nancy Vinch, Sr. He received his Bachelor of Science degree in mechanical

engineering, graduating with honors, from the Rochester Institute of Technology in May

of 2000. In August of 2000, he enrolled at the University of Florida and entered the

master's program in the Department of Mechanical and Aerospace Engineering. Upon

graduation from the University of Florida, he plans to work in the area of autonomous

vehicle development.











University of Florida Graduate School
Electronic Thesis and Dissertation (ETD) Rights
and Permission

1. Enter and submit on line. 2. Print, sign, and submit to Graduate School Editorial Office

Student Name: Peter M. Vinch, Jr.

ID#: 6566-1370

Document Type: V Master's Thesis Doctoral Dissertation

Document Title: Design and Implementation of an Intelligent Primitive Driver


Student Agreement:


I hereby certify that I have obtained all necessary permission in writing for copyrighted material to be published in my
thesis or dissertation. Further, I certify that I have obtained and attached hereto a written permission statement from the
owners) of any copyrighted matter to be included in my thesis or dissertation, allowing distribution as specified below.
Copies of all such permissions are maintained in my files.

I hereby grant to the University of Florida and its employees the nonexclusive license to archive and make accessible,
under the conditions specified below, my thesis or dissertation in whole or in part in all forms of media, now or
hereafter known. This is a license rather than assignments, and I, therefore, retain all other ownership rights to the
copyright of the thesis or dissertation. I also retain the right to use in future works (such as articles or books) all or part
of this thesis or dissertation.

In addition to the unrestricted display of the bibliographic information and the abstract, I agree that the above
mentioned document be placed in the ETD archive with the following status (choose one of 1,2, or 3) by checking the
appropriate space below):
1 1. Release the entire work immediately for access worldwide.
S2. Restrict access to the entire work to the University of Florida and all patrons of its libraries, including
interlibrary sharing and release of doctoral dissertations to UMI. [Please check appropriate time span.]
After (_1, 2, 3, 4, 5, _10) years release my work worldwide unless you receive in writing a request
from me to continue restricted access. If I choose to release the work for worldwide access sooner, I will
contact Library Archives, P.O. Box 117007, University of Florida, Gainesville, FL 32611.
S3. Secure the entire work for patent and/or proprietary purposes for a period of six months. During this period the
copyright owner also agrees not to exercise her/his ownership rights, including public use in works, without
prior authorization from the University of Florida. At the end of the six-month period, either I or the
University of Florida may request an extension for an additional six months. At the end of the six-month
secure period (or its extension, if such is requested), the work will be handled under option 1 above, unless I
request option 2 in writing.

The undersigned agrees to abide by the statements above, and agrees that this approval form updates any and all
previous approval forms submitted heretofore.

Signed:
(Student) (Date)


(Chair)


(Date)










University of Florida Graduate School
Electronic Thesis and Dissertation (ETD) Signature Page


Student's Name: Peter M. Vinch, Jr.

This document has been reviewed and accepted by the student's supervisory committee.


Professor's name & title including department Professor's signature


Name Carl D. Crane, III I Chair
Title Professor of Mechanical and Aerospace Engineering


Name John K. Schueller
Title Professor of Mechanical and Aerospace Engineering


Name Eric M. Schwartz a
Title Lecturer of Electrical and Computer Engineering


Name
Title


Name
Title


Name
Title

Name

Title

Month and Year of Graduation: August 2003


College Dean:
(when required by college)
Name
Title
Graduate Dean:

You do not provide this signature. The
Editorial Office will ask the Graduate School
Dean to sign it later, after commencement.




Full Text

PAGE 1

DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER By PETER M. VINCH, JR. A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Peter M. Vinch, Jr.

PAGE 3

What we call the beginning is often the end. And to make an end is to make a beginning. The end is where we start from. T.S. Eliot, Four Quartets

PAGE 4

ACKNOWLEDGMENTS There are many individuals, on professional and personal fronts, whom I would like to thank for making possible the preparation and completion of this thesis. Professionally, I would like to thank Dr. Carl D. Crane, III (my academic advisor and chair of my graduate committee) for his direction, advice and encouragement. I also greatly appreciate the time and energy that the other members of my supervisory committee (Dr. John K. Schueller and Dr. Eric M. Scwartz) dedicated to my cause. I would like to extend my gratitude to the Nuclear and Radiological Engineering Department of the University of Florida for allowing me the use of their Remotec Andros robot for testing purposes. I thank the U.S. Department of Energy (Grant #DE-FG04-86NE37967) and the Air Force Research Laboratory located at Tyndall Air Force Base, Florida (contract # F08637-00-C6008) for all of their support. I am also grateful to the entire staff of the Center for Intelligent Machines and Robotics, for all of their assistance with the completion of my thesis. Additionally, I would like to distinguish the contributions of Shannon Ridgeway, Daniel Kent, Carl P. Evans, III, and especially Dr. David Keith Novick for all of their professional advice and the friendship that they have extended to me. Without these individuals, none of this would have been possible. Personally, I would like to thank all of my friends and family for their efforts to keep me sane and functional. Key people in this effort were Andrew and Gretchen McGraw, whose friendship, support and love I will always value. I would also like to thank Adam Feinberg for being such a great roommate, lifting partner, and best friend. He has pushed iv

PAGE 5

me to become better in every aspect of my life; and for this I will always be grateful. Of course, without the love and support of my family, all of my efforts would be fruitless. Therefore, I would like to thank my mother, Nancy; my two sisters, Bridget and Melissa; and my grandfather, Philip. Finally, I would like to thank my father, Peter M. Vinch, Sr.; and my uncle, Robert Frie. These men have been my greatest influences, helping to place me on the proper path through life. Without them, I would have been lost. v

PAGE 6

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES...........................................................................................................viii LIST OF FIGURES...........................................................................................................ix ABSTRACT.......................................................................................................................xi CHAPTERS 1 INTRODUCTION AND BACKGROUND....................................................................1 1.1 Introduction...............................................................................................................1 1.2 Background...............................................................................................................1 1.2.1 Assisted Teleop Control..................................................................................1 1.2.2 Stair Climbing.................................................................................................3 1.3 The Joint Architecture for Unmanned Systems (JAUS)...........................................4 1.3.1 Overview.........................................................................................................4 1.3.2 System Topology.............................................................................................6 1.3.3 The JAUS Component.....................................................................................7 1.3.4 The JAUS Message.........................................................................................7 2 TEST PLATFORM DEVELOPMENT.........................................................................10 2.1 Remotec Andros Robot...........................................................................................10 2.2 Andros JAUS Controller.........................................................................................12 2.3 Sensor Systems.......................................................................................................15 2.3.1 Stair Counter Assembly.................................................................................15 2.3.2 Auxiliary Track Positioning System.............................................................20 2.3.3 JAUS Positioning System.............................................................................21 2.4 Operator Control Unit.............................................................................................22 3 INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION............24 3.1 Component Definition............................................................................................24 3.1.1 Component Function.....................................................................................24 3.1.2 Component I/O..............................................................................................24 3.1.3 Component Description.................................................................................25 vi

PAGE 7

3.1.4 IPD Input and Output Messages....................................................................27 3.1.4.1 "Set Auxiliary Actuators"...................................................................27 3.1.4.2 "Query Auxiliary Actuators"..............................................................28 3.1.4.3 "Report Auxiliary Actuators".............................................................28 3.1.4.4 "Set Behavior X"................................................................................28 3.1.4.5 "Query Behavior X"...........................................................................29 3.1.4.6 "Report Behavior X"..........................................................................29 3.2 Intelligent Primitive Driver Application.................................................................30 3.2.1 Fuzzy Logic...................................................................................................30 3.2.2 Functionality..................................................................................................31 3.2.3 Program Logic...............................................................................................32 3.2.4 Ascend Protocol 1.........................................................................................39 3.2.5 Ascend Protocol 2.........................................................................................39 3.2.6 Descend Protocol 1........................................................................................41 3.2.7 Descend Protocol 2........................................................................................42 4 TESTING AND RESULTS...........................................................................................43 4.1 Stair-Counter Assembly..........................................................................................43 4.1.1 Testing Procedure..........................................................................................43 4.1.2 Results...........................................................................................................46 4.2 Auxiliary Track Positioning System.......................................................................48 4.2.1 Testing Procedure..........................................................................................48 4.2.2 Results...........................................................................................................50 4.3 Heading Alignment Controller...............................................................................52 4.3.1 Testing Procedure..........................................................................................52 4.3.2 Results...........................................................................................................52 5 CONCLUSIONS AND FUTURE WORK....................................................................55 5.1 Conclusions.............................................................................................................55 5.2 Future Work............................................................................................................59 APPENDIX A. STANDARD JAUS MESSAGES................................................................................61 A.1 Query Global Pose.................................................................................................61 A.2 Set Wrench Effort..................................................................................................61 A.3 JAUS Core Message Set........................................................................................63 B. STAIR COUNTER MATHEMATICAL DEVELOPMENT.......................................64 LIST OF REFERENCES...................................................................................................69 BIOGRAPHICAL SKETCH.............................................................................................71 vii

PAGE 8

LIST OF TABLES Table page 1-1 Message header data format.......................................................................................8 3-1 User defined input and output JAUS commands......................................................25 3-2 Set Auxiliary Actuators command fields..............................................................27 3-3 Query Auxiliary Actuators command field...........................................................28 3-4 Set Behavior X command fields...........................................................................29 3-5 Query Behavior X command field........................................................................29 3-6 "Set Behavior" 1 and 2 control data.........................................................................32 A-1 Query Global Pose data field...............................................................................61 A-2 Set Wrench Effort data fields...............................................................................62 A-3 Core message set......................................................................................................63 viii

PAGE 9

LIST OF FIGURES Figure page 1-1 Architecture hierarchy................................................................................................7 1-2 Message header properties bit layout.........................................................................9 2-1 Remotec Andros robotic platform............................................................................10 2-2 Andros physical dimensions.....................................................................................11 2-3 Native Andros controller..........................................................................................12 2-4 Communicator-Node Manager component interaction............................................13 2-5 Primitive Driver component interaction...................................................................14 2-6 Vehicle orthogonal coordinate system.....................................................................15 2-7 Stair counter assembly..............................................................................................16 2-9 Median filter example...............................................................................................18 2-10 Auxiliary track position system setup......................................................................20 3-1 Intelligent Primitive Driver implementation............................................................26 3-2 Intelligent Primitive Driver logic flow diagram.......................................................33 3-3 Set Auxiliary Actuator algorithm..........................................................................34 3-4 Opening sequence of Set Behavior X algorithm...................................................35 3-5 Stair data representation...........................................................................................36 3-6 Skew alignment task correction................................................................................37 3-7 Ascend stair motion protocol....................................................................................40 3-8 Descend stair motion protocol..................................................................................41 4-1 Calibration data for Sharp GP2D12 infrared object detectors..................................44 ix

PAGE 10

4-2 Stair-counter testing assembly..................................................................................45 4-3 Stair-counter data......................................................................................................47 4-4 Plumb compass attached to Andros auxiliary track..................................................48 4-5 Controller commanded halt angle and actuator halt angle versus operator commanded angle....................................................................................................50 4-6 Controller commanded halt error and actuator halt error versus operator commanded angle....................................................................................................51 4-7 Controller commanded halt heading and vehicle halt heading versus operator commanded heading................................................................................................53 4-8 Controller commanded heading error and vehicle heading error versus operator commanded heading................................................................................................54 5-1 Controller mounted on Andros platform..................................................................56 B-1 Stair representation...................................................................................................64 B-2 Stair runner model.....................................................................................................65 B-3 Stair riser model........................................................................................................67 B-4 Calculated distances, d, for varying value of .........................................................68 x

PAGE 11

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science DESIGN AND IMPLEMENTATION OF AN INTELLIGENT PRIMITIVE DRIVER By Peter M. Vinch, Jr. August 2003 Chair: Carl D. Crane, III Department: Mechanical and Aerospace Engineering An Intelligent Primitive Driver (IPD) was designed to supplement the control of a Primitive Driver component that is defined in the Department of Defense Joint Architecture for Unmanned Systems (JAUS). Whereas the Primitive Driver component accepts and blindly executes wrench commands, the IPD uses various subsystems to provide it with the necessary information to make low-level decisions concerning vehicle control. The IPD is accessible by either an onboard autonomous control system; or by a tele-operational control system. Tele-operational control (teleop) is characterized by the direct control of a platform by a human operator. For the case of an autonomous control system, the IPD reduces high-level control responsibilities; and therefore reduces processor demands. In the case of teleop control, the IPD serves to ease operator burden by automating intensive operator-controlled processes. The test platform for the functionality of the Intelligent Primitive Driver was a Remotec ANDROS robot. In the case of the ANDROS robot, the IPD automates the process of maneuvering up or down a flight of stairs. xi

PAGE 12

CHAPTER 1 INTRODUCTION AND BACKGROUND 1.1 Introduction The purpose of this research was to design and develop an experimental intelligence component based on the Joint Architecture for Unmanned Systems (JAUS), currently being developed in concert with the Department of Defense. This component will be designated the Intelligent Primitive Driver (IPD) and will allow for assisted tele-operational (teleop) control of a platform. Teleop control can be defined as the control of a vehicle or robot by the direct input of a human operator. Assisted teleop is based upon this concept, but includes additional computer control to supplement the operators control; intensive control procedures were automated to ease the burden on the operator. The IPD accomplished this task by having direct control of any and all actuators that directly affect the motion of the platform. A Remotec Andros robot, outfitted with a JAUS-compliant controller, was used to test the viability of the IPD. In the case of the Andros, the IPD automated the complicated stair ascending and descending operations. 1.2 Background 1.2.1 Assisted Teleop Control The human-machine relationship has always been clearly defined: machines are controlled by humans and are constructed to ease the burdens of human life. However, two recently developing factors have begun to dramatically change this relationship. 1

PAGE 13

2 First, an increase in computing power and system reliability along with a decrease in size and power requirements of modern control systems have made possible the shift of some control responsibility from the human operator to the controller itself. Bayouth and colleagues [1] (of the Robotics Institute of Carnegie Mellon University) constructed an autonomous roadway vehicle that demonstrated lane following, speed and heading compliance, and obstacle avoidance in an effort to increase vehicle safety and mobility. Several other groups have also worked on the Intelligent Cruise Control concept. The Mustererkennung und Szenenanalyse Pattern Recognition and Scene Analysis (MESA) research group [2] have developed behaviors (such as tracking a lead vehicle or lane changing) that comprise a basic control set on which more complicated procedures are based. Schlegel [3], in his thesis, Autonomous Vehicle Control using Image Processing, tested the intelligent cruise control notion through the use of scale models coupled with a remote control station aimed at emulating full-scale vehicle controls. The second factor that has influenced the human-machine interface is the growing complexity of the platforms being automated and the tasks they are able to perform. Connell and Viola [4] (of the IBM T.J. Watson Research Center) have a novel way of describing the problems with traditional platform control systems: Consider the differences between riding a horse and driving an automobile. A horse will not run into a telephone pole at high speed. If you fall asleep in the saddle, a horse will continue to follow the path that it is on. In general, horses are much smarter than automobiles and thus provide a better model for control of a mobile robot. [4] Connell and Viola constructed a platform and control system that cast the operator as an agent in the control system, able to input commands into the arbitration network, as well as a high-level command language that was able to shut out individual control agents.

PAGE 14

3 Huntsberger and Rose [5], of the Jet Propulsion Laboratory (JPL) and the University of South Carolina (USC), respectively, are working on a behavior-based control system named BISMARC, or the Biologically Inspired System for Map-based Autonomous Rover Control, for use with the Mars rover platforms. They utilize a form of path planning that is derived from the study of human navigation through complex environments. 1.2.2 Stair Climbing For mobile robotic platforms to be useful in urban environments, they need to be able to easily traverse commonly found terrain features, such as stairways. Several detection methods are used to enable platform navigation on these non-continuous planar structures (such as vision-based positioning and edge detection, laser-based edge detection, and the fusion of several sensor systems). Others have solved the dilemma by manipulating the physical characteristics of the platform to suite the special needs of a stair-climbing vehicle. Matthies, et al. [6] constructed a small mobile platform capable of performing reconnaissance duties in urban situations. To meet the stair climbing requirements associated with this detail, a vision-guided navigation and detection system was implemented on the robot. A stereovision system was used to detect the forward edges of individual steps. This information was used to derive the angle of rotation between the robot and the stairway; and to ensure that the robot was accurately following the stair heading. Lewis and Simo [7] (Iguana Robotics, Inc.) built a bipedal platform based on the biomorphic concept capable of stair travel (Figure 1-1). Basically, a biomorphic robot attempts to mimic the sensory capabilities of animals; sensory input is predicated upon

PAGE 15

4 voluntary movement of the platform and must be distinguished from possible inputs produced by the platform itself. The platform fused stereovision; and tactile and pressure sensors to build an accurate data model of the terrain to traverse. Another application of the biomorphic concept is the work of Talebi, et al. [8]. They constructed a quadruped platform that has only one actuator per leg coupled with compliant prismatic joints. Therefore, as an animal would, the platform climbs a stair dynamically. As the leg contacts the stair, ground forces cause the joint spring to compress; and the effective length of the leg is reduced. Perhaps the most stable solution for the stair-climbing problem, when the development of the platform permits, is to tailor the geometry to accommodate the stair climbing motion. Lauria, et al. [9] took this approach in developing their vehicle, Octopus. The platform consists of eight motorized, tactile wheels and a tilt sensor; and has a total of fifteen degrees of freedom. The platform geometry allows for all eight wheels to be in contact with the ground at all times, regardless of the terrain profile; allowing for relatively simple travel of the platform across any uneven terrain, stairways included. 1.3 The Joint Architecture for Unmanned Systems (JAUS) This section provides a functional description of the Joint Architecture for Unmanned Systems (JAUS). The technical constraints on the architecture, system topology, standard component definition, and the JAUS message will be discussed. 1.3.1 Overview The JAUS architecture is being developed in conjunction with the Department of Defense in support of unmanned vehicle systems development and provides a means for reducing system life-cycle costs by offering a well-defined component interface. This

PAGE 16

5 interface allows for the future reuse of expensive components in developing autonomous systems and also allows for the quick exchange of malfunctioning or outdated components in current autonomous systems. Further, the engineer is free to place all available resources into obtaining optimal performance from the component as its interface is predefined [10]. The JAUS architecture is divided into three separate volumes: the JAUS Domain Model, Document Control Plan, and Reference Architecture. The JAUS Domain Model defines both known and prospective operational requirements of unmanned systems, while the Document Control Plan describes the procedure used to recognize and track changes to accepted JAUS documents. This work will focus solely upon the Reference Architecture as it is concerned with aspects of component design. The reference architecture defines components, messages and standards that classify a system paradigm, which allows for the assimilation of distributed system architectures. The reference architecture is comprised only of components and messages that have been technically evaluated by the tech base, academia, or an industry source and whose implementation is thoroughly understood. Therefore, the incorporation of components, their classification, and their corresponding messages is an evolutionary process [10]. There are four technical constraints, which have been levied upon the JAUS architecture to ensure that it may be freely applied to any classification of unmanned system. These constraints are platform independence, mission isolation, computer hardware independence, and technological independence. To be platform independent, no assumptions concerning vehicle platforms to be automated will be incorporated into the definition of any JAUS component. The JAUS architecture defines a mission as the

PAGE 17

6 ability to gather information about or to alter the state of the environment in which the platform is operating. Therefore, the mission isolation constraint is intended to allow the engineer to construct systems that can support a variety of missions, not just a single one. The computer hardware independence constraint insists that the component be designed independent of the computer system upon which the component will run. This was included in the architecture so that currently used components can be applied to future computer systems without modification to the component. This allows new computer architectures to be easily inserted into current systems, extending its life cycle. This also allows for hardware flexibility, as the appropriate hardware may be applied to each system. Finally, technological independence is similar to computer hardware independence, but instead deals with the action to be performed by the component instead of the system that is performing the action. This constraint basically states that the architecture will make no assumptions concerning the method by which an action is performed. For example, in a JAUS compliant position system, no assumptions are made concerning the method in which the vehicle position is obtained. Any method of obtaining vehicle position is allowable, from a Global Positioning System (GPS), dead reckoning, inertial measurement, a vision based position system, or any subsequent positioning system [10]. 1.3.2 System Topology There are four elements, which comprise the hierarchy of the JAUS architecture: the System, Subsystem, Node, and Component/Instance. A System is a logical grouping of one or more Subsystems, which have been grouped such that beneficial cooperation between the Subsystems can be achieved. A Subsystem is a distinct organism, which is comprised of any number of Nodes necessary to form a complete unmanned system. A

PAGE 18

7 Node is a distinct entity, comprised of a single processor or multiple processors working in conjunction with each other, to provide a complete service. Finally, a Component is a cohesive software process, which runs on a Node. An Instance is a single occurrence of a Component running on a Node. Several Instances of the same Component may run on a single Node, and are delineated by unique addresses. Figure 1-1 illustrates the interaction of these four levels [10] SYSTEM Subsystem Subsystem Subsystem Node Node Node Node Comp1, Inst1 Comp2, Inst1 Comp2, Inst2 CompN, Inst1 Figure 1-1: Architecture hierarchy (used from JAUS: Reference Architecture Specification, pg. 12) 1.3.3 The JAUS Component As JAUS is a hierarchical system of components with standardized interfaces, the JAUS Component is a strictly defined entity. A distinct name and identification number defines a JAUS Component and every JAUS Component shall perform a single, cohesive function. Each Component must be able to accept and act upon the set of core JAUS command codes, as well as the input and output codes specific to the individual Component itself. A list of the core JAUS command codes may be found in Appendix A [10]. 1.3.4 The JAUS Message A JAUS message is comprised of two distinct components: the message header and the message data buffer. The message header completely defines the messages

PAGE 19

8 destination node, component, instance and subsystem identification, and the messages corresponding source information. The message header also consists of the JAUS command code, the number of bytes in the data buffer that the destination component can expect to receive, and information pertaining to the message properties, such as the JAUS architecture version being used. The message header data is found in Table 1-1 while the bit field layout for the message properties can be seen in Figure 1-2. Table 1-1: Message header data format (used from JAUS: Reference Architecture Specification, pg. 54) Field # Field Description Size (Bytes) 1 Message properties 2 2 Command code 2 3 Destination instance ID 1 4 Destination component ID 1 5 Destination node ID 1 6 Destination subsystem ID 1 7 Source instance ID 1 8 Source component ID 1 9 Source node ID 1 10 Source subsystem ID 1 11 Data control (bytes) 2 12 Sequence number 2 Total Bytes 16 The message data buffer is composed of packed JAUS control data. Each command code has control data associated with it that is used by the system to command component behavior. In an effort to reduce the size of the JAUS messages being transmitted, and therefore reduce the required bandwidth of the system, the message data is compressed before being transmitted. To accommodate this, the JAUS code library for

PAGE 20

9 each component and its subsequent command codes must have the ability to pack and unpack the control data. Message PriorityRange 0..15Default Priority 6Normal Priority Range 0..11Safety Critical Range 12..15 ack/nak0 -None, 1 -Request ack/nak2-nakresponse 3 -ackresponse 76543210Most significant bitLeast significant bit Service Connection Flag1 -Service Connection, 0 -Not Experimental Message Flag0-JAUGS, 1 -Experimental VersionRange 0..63Version 2.0 = 0Version 3.0 = 12..63 unused8 Reserved131415 Reserved Message PriorityRange 0..15Default Priority 6Normal Priority Range 0..11Safety Critical Range 12..15 ack/nak0 -None, 1 -Request ack/nak2-nakresponse 3 -ackresponse 76543210Most significant bitLeast significant bit Service Connection Flag1 -Service Connection, 0 -Not Experimental Message Flag0-JAUGS, 1 -Experimental VersionRange 0..63Version 2.0 = 0Version 3.0 = 12..63 unused8 Reserved131415 Reserved Figure 1-2: Message header properties bit layout (used from JAUS: Reference Architecture Specification, pg. 54)

PAGE 21

CHAPTER 2 TEST PLATFORM DEVELOPMENT To investigate the Intelligent Primitive Driver, a test platform first needed to be outfitted with a JAUS compliant control system. Due to the availability of indirect motion actuators on the system and its relatively complicated stair climbing procedures, a Remotec Andros robot was chosen for this task. 2.1 Remotec Andros Robot Figure 2-1 depicts the Remotec Andros robot. As stated in the instruction manual, the primary design purpose of the Andros is to provide an effective means for remote Explosive Ordnance Disposal (EOD) Andros robots are currently used to remotely perform a variety of hazardous work tasks including explosive handling, tactical support operations, and nuclear plant maintenance [11]. Figure 2-1: Remotec Andros robotic platform The robot consists of a main chassis, front and rear sets of auxiliary tracks, and the main arm assembly. The tracks are made of Kevlar belts with molded internal and external urethane cleats. The auxiliary tracks are able to swing from +85 degrees to 10

PAGE 22

11 degrees relative to the horizontal position. The drive motors are able to propel the Andros up forty-five degree slopes or stairs and can maintain the vehicles position upon a slope through dynamic braking. The physical dimensions of the Andros are seen in Figure 2-2 [11]. Figure 2-2: Andros physical dimensions Figure 2-3 depicts the native Andros controller. Upon power up of the Andros system, the native control transmits an initialization string to the Andros embedded controller and then begins the continuous output of the control data. The Andros embedded controller will only enter the ready state and accept platform control data if the initialization string is properly sent and the control data is received at a maximum 5 Hz frequency. The controller uses a proprietary serial control stream to communicate with the Andros embedded controller. The update frequency is the absolute maximum rate at which any controller may update the control data being sent to the Andros and therefore alter the Andros intended motion. 3228 3228 To use the Andros robot as the test platform for the IPD system, the JAUS control system implemented on the Andros had to be completely removable from the system so that the native Andros controller could be reconnected and used to control the Andros.

PAGE 23

12 To meet this interoperability constraint, the JAUS control system mimicked the serial control stream of the native controller. To achieve this, the control stream and initialization string were reversed engineered from the output of the native controller; however, the specific information pertaining to the Andros control data bytes may not be disseminated because of a nondisclosure agreement entered into between the Center for Intelligent Machines and Robotics (CIMAR) laboratory, located at the University of Florida, and Remotec, the manufacturer of the Andros platform. Figure 2-3: Native Andros controller 2.2 Andros JAUS Controller The Andros JAUS controller operates on a RabbitCore RCM3200 microcontroller, which utilizes a Rabbit 3000 microprocessor running at 44.2 MHz. The RCM3200 has an integrated 10/100Base-T Ethernet port and six available serial ports for communications, as well as 44 configurable, 5 volt tolerant, I/O lines. The RCM3200 runs the Dynamic C Premier Version 7.33P3 real time operating system, in which the four basic JAUS components that comprise the Andros control system were coded.

PAGE 24

13 These components are the Communicator, Node Manager, Primitive Driver, and Position System. Libraries for each component were coded following the specifications found in the JAUS Reference Architecture. Component A Node Manager Communicator Communicator Node Manager Component B Ethernet Node ANode B Figure 2-4: Communicator-Node Manager component interaction Two JAUS components are directly responsible for all inter-component communications: the Communicator and the Node Manager. As such, all nodes must support both a Communicator and a Node Manager component. The Communicator allows for a single point of message entry into a subsystem while maintaining the data link between the subsystems. The Andros Communicator uses a User Datagram Protocol (UDP) Ethernet connection for all communications. The Node Manager component controls the routing of JAUS messages from one node to another. As depicted in Figure 2-4, a JAUS message is spawned within a component and then sent to the Node Manager, where the information pertaining to the destination component and destination node are attached to the message. This fully defined JAUS message is now passed on to the communicator, which handles the transmission of the message to the proper node [10].

PAGE 25

14 SystemCommander Primitive Driver CommandedWrench EffortVehicle SpecificActuator Commands Figure 2-5: Primitive Driver component interaction The Primitive Driver is a component, which accepts wrench commands from the System Commander and resolves them into vehicle specific actuator signals, thus initiating vehicle motion, as seen in Figure 2-5. A wrench command consists of six propulsive and six resistive elements, with each set consisting of three linear force elements and three rotational moment elements. These elements are then mapped to the three axis orthogonal coordinate system assigned to the vehicle, as shown in Figure 2-6. It is worth noting that every element of a wrench message is not necessarily applicable to every vehicle. For example, a wheeled vehicle typically only requires three elements of the wrench message to control it properly: the resistive and propulsive linear forces in the x direction and the rotational moment in the z direction [10].

PAGE 26

15 The Position System is concerned solely with the determination of the vehicles global position and orientation and is necessary for the controller to perform accurate autonomous motion. The vehicles position and orientation information is provided to the system upon receipt of a Query Global Pose command from either the Operator Control Unit or the Intelligent Primitive Driver. Ground Plane z y x Figure 2-6: Vehicle orthogonal coordinate system 2.3 Sensor Systems There are three main sensor systems used by the Andros system: the stair counter assembly, the auxiliary track position system, and the JAUS positioning system. These systems provide feedback essential to the controllers ability to execute behavioral commands. 2.3.1 Stair Counter Assembly For the stair-climbing algorithms to function properly, the control system needs to know the relative position of the Andros on the stairs. Typically, a Global Positioning System (GPS) would be used to provide location information in a robotic system. However, staircases are found in or around buildings, which generally limit the effectiveness of a GPS system; if satellite transmissions to the GPS receiver are blocked

PAGE 27

16 by the structure housing the staircase, no position information will be acquired. Therefore, the stair counter assembly was designed to provide the relative position of the Andros upon the staircase by counting the number of stairs that the Andros has passed and is able to account for a step while moving in either direction upon a staircase. For example, while climbing the stairs, the Andros passes four steps. While attempting to move to the fifth step, a slippage error occurs and the Andros slides back down two steps. The stair counter is able to take this error into account and update the current position of the Andros upon the stairs. In this case, the Andros would now be located at the second step. Figure 2-7: Stair counter assembly The stair counter assembly consists of an array of two Sharp GP2D12 infrared object detectors. These sensors take continuous distance readings up to 80 cm, have an update Infrared Sensors Shroud Mounting Plate

PAGE 28

17 rate of 31.25 Hz, and are interfaced by the RabbitCore microcontroller through the use of a TLC545 Texas Instruments analog-to-digital converter. The sensors are positioned one in front of the other with a one-inch offset and are orientated such that their detection beams are perpendicular to the long axis of the Andros, as seen in Figure 2-7; the sensors point directly at the plane upon which the Andros is situated. Both sensors are shrouded to limit the amount of interference they may receive from ambient light sources and from each other. -1.4-1.2-1-0.8-0.6-0.4-0.200.20.444.555.566.5Time (sec)Distance (in) Series1 Stair Data1st Derivative2nd Derivativ e Impulse Figure 2-8: Infrared sensor stair representation

PAGE 29

18 Each infrared sensor constructs a digital representation of the staircase as the Andros moves on it by determining the distance from the sensor to the staircase. By assuming that the vehicle maintains a relatively constant velocity upon the staircase, the derivative of the stair data can be found by simply taking the difference of the current data point and the previous data point collected. The second derivative of the stair data can now be obtained by taking the difference of the first derivative data. Figure 2-8 depicts a sample stair data representation for a single infrared detector and the corresponding first and second derivative data. The graph has been cropped to emphasize the range of pertinent data. The data for the stair representation was simulated using a mathematical model of the sensor system, with the first and second derivative data obtained as outlined above. For the simulation, the rise of a single step was set at 8 inches, the run was set at 10 inches, and a 0.1 second sampling rate was used. Derivation of the mathematical model of the sensor system can be found in Appendix B. 43549514334411445554559995445554 Sorted Data Filtered Data Raw Data Figure 2-9: Median filter example

PAGE 30

19 To account for noise in the infrared detection signals, the first derivative data is filtered using a three element median filter before the second derivative is calculated. Median filtering is a non-linear filtering technique useful for the suppression of impulse noise and the smoothing of edges. It works by taking a set number of data points and determining the mathematical median of them, which then replaces the data point. An example of a three element median filter is shown in Figure 2-9. In this example, three elements of the raw data are grouped together and sorted from low to high. In this configuration, the median of the data is simply the middle of the three numbers, which is now the filtered data point [12]. The impulses in the second derivative data represent inflection points on the stairs; the interior concave stair corner will yield a positive impulse while an exterior convex stair corner will yield a negative impulse. The system accounts for the stairs that the Andros has passed by detecting these impulses; if the impulse that is less than a given threshold value, a stair is counted. The direction of travel upon the stairs, and therefore whether to add or subtract a stair to the total number counted, is determined by which sensor detected the impulse first. If the front detector senses the impulse before the rear, then a stair is added. If the rear detector senses the impulse before the front, then a stair is subtracted from the total. The computation of the first and second derivatives of the stair representation and the application of the median filter induces a delay in the detection of the stair inflections. Each of the derivative computations account for a one-cycle delay, while the median filter accounts for a three-cycle delay for a total delay of five cycles. As the detectors are

PAGE 31

20 polled at a rate of 20 Hz, the total delay time is 0.25 seconds between acquisition of the stair data and detection of a stair inflection. The stair counter assembly also has an end of world capability, meaning that it can be used for detection of drop-offs and ledges. The system uses this function to determine the edge of a landing when descending a set of stairs. The edge is detected by monitoring the output of the infrared sensors: the distances measured will remain constant until the sensor reaches a point when it is directly over the first step. At this point, there will be a drastic change in the measured distance, which the system interprets as the edge of the landing and the beginning of the stairs. Figure 2-10: Auxiliary track position system setup Andros Chassis Auxiliary Track Assembly DWT Senso r Auxiliary Trac k Sensor Cable 65 o 150 o 0 o 2.3.2 Auxiliary Track Positioning System A Draw-Wire Transducer (DWT) sensor, manufactured by UniMeasure, is used to measure the angle of the Andros auxiliary tracks, one each for the front and rear tracks.

PAGE 32

21 This sensor was used over other forms of angular sensors, such as rotary or optical encoders, because of its ease of setup and robust mechanical interface; there are no gears to become jammed with dirt or optical sensors to become inoperable because of grime. The DWT is simply a spring-loaded potentiometer connected to a three-foot long cable. The DWT sensor is attached to the chassis of the Andros, with the draw cable being wrapped around the auxiliary track drum once and then attached to it via a 10-32 cap-head screw. The setup is shown in Figure 2-10. A 5-volt reference voltage is applied to the sensor, which will return from 0 to 5 volts proportional to the length of cable drawn from the sensor. The governing equation for the angle measured by the system is given in Equation 2-1, where V high and V low are the upper and lower voltage bounds observed by the sensor and V measured is the sensor voltage. The DWT sensors are interfaced by the RabbitCore microcontroller through the use of a TLC545 Texas Instruments analog-to-digital converter. 150*lowhighlowmeasuredVVVV (2 1) 2.3.3 JAUS Positioning System As there is no GPS being used on the Andros system, the position system is comprised solely of a PNI Corporation TCM2-20 tilt-compensated module to update the Andros heading. The compass heading of the Andros is filtered using a three element median filter, as previously described. The TCM2-20 is based upon PNI Corp.s proprietary triaxial magnetometer system and its biaxial electrolytic inclinometer. When level, it is accurate to within +/0.5

PAGE 33

22 degrees RMS with 0.1-degree resolution. This changes to +/1 degree RMS when the system is on an incline. It communicates via a 38.6 kBaud, RS-232 serial connection and is set to run at a sampling rate of 20 Hz. The digital compass experiences a computation delay, much in the same manner as the stair counter system. The three element median filtering produces a delay of three cycles, which corresponds to a delay of 0.15 seconds between acquisition of the heading data and realization of the filtered heading. 2.4 Operator Control Unit In order for the Andros JAUS control system to be fully operable, an Operator Control Unit (OCU) was developed on a Gateway Solo 3350 laptop with the Linux Redhat 8.0 operating system. A Netgear ME102 Wireless Access Point is used to establish a wireless Ethernet connection with the Andros JAUS controller. The access point uses the IEEE 802.11b standard and transmits up to 11 Mpbs at 2.4 to 2.5 GHz. To be able to communicate with the JAUS components located on the Andros platform, the OCU needed to have information pertinent to the construction of the JAUS messages required to command these components available. Therefore, JAUS message libraries for the Primitive Driver and Position System components were coded for the Linux operating system. These libraries were adapted from code obtained from Dr. Jeff Wit of Wintech, Inc. Communicator and Node Manager components were also coded for the Linux operating system to allow the OCU to interact with the Andros JAUS components. All of the OCU components were developed in parallel with the corresponding components used on the Rabbit microcontroller. The OCU console was developed using the Linux Curses library. This was chosen for the basis of the user interface because it allows for the easy manipulation of the

PAGE 34

23 terminal display regardless of the terminal type used. The Curses library only supports the use of single byte characters for display, but this was more than adequate to meet the needs of this OCU.

PAGE 35

CHAPTER 3 INTELLIGENT PRIMITIVE DRIVER DEFINITION AND APPLICATION This chapter defines the Intelligent Primitive Driver (IPD) in terms of the JAUS architecture. It then details the application of the Intelligent Primitive Driver to the Andros system. 3.1 Component Definition For the IPD to be considered a JAUS component, it needs to fit into the rigid framework that comprises the architecture. Therefore, the component will be defined as per the specifications detailed in the JAUS Reference Architecture: the component function, input and output messages, and description will be defined. The component has been assigned the component identification number of 99 [10]. 3.1.1 Component Function The Intelligent Primitive Driver component is responsible for the control of all indirect motion related actuators. An indirect motion related actuator is any actuator that affects the ability of a platform to perform a commanded motion, but does not perform that motion itself. For example, on the Andros robot, the front and rear auxiliary tracks are considered indirect motion actuators. They are responsible for aiding the Andros in moving over rough and uneven terrain, but do not directly produce the motion. 3.1.2 Component I/O The IPD will accept any of the JAUS core input and output messages, as well as the Set Wrench Effort and Query Global Pose commands. These commands are as 24

PAGE 36

25 defined in Appendix A. Table 3-1 shows the user defined set of input and output messages and their corresponding unique command codes. The input and output command sets will be completely defined in the Input and Output Commands section later in this chapter. Table 3-1: User defined input and output JAUS commands Command Code Description 0x1FF1 Set Auxiliary Actuator 0x1FF2 0x1FF9 Set Behavior X IN 0x3FF1 Query Auxiliary Actuator 0x3FF2 0x3FF9 Query Behavior X 0x5FF1 Report Auxiliary Actuators OUT 0x5FF2 0x5FF9 Report Behavior X 3.1.3 Component Description The IPD defines a command interface to control any available indirect motion actuators available upon a platform and any subsequent set of vehicle behaviors that would utilize these actuators. Further, the IPD is able to issue wrench commands to a primitive driver component. Automation of vehicle behaviors is accomplished to ease operator burden when the JAUS system is acting in tele-operational mode and to decrease high-level processor load when the system is acting in full-autonomous mode. Similar to the Primitive Driver component, the IPD does not imply any specific platform in its definition and therefore is not completely defined until it has been applied to the control system of a particular platform. Figure 3-1 illustrates the most basic implementation of the Intelligent Primitive Driver into the JAUS system architecture. The System Commander may send commanded wrench efforts to the primitive driver to initiate vehicle motion or any of the

PAGE 37

26 aforementioned IPD command codes to the Intelligent Primitive Driver either to control an indirect motion actuator or start a vehicle behavior. If a command is sent to begin a vehicle behavior, the IPD is able to send vehicle specific commands directly to the vehicle to control the indirect motion actuators. Also, if vehicle motion is necessary to accomplish the behavior, the IPD may send commanded wrench efforts to the primitive driver component to incite vehicle motion. System Commander PrimitiveDriverCommandedWrench EffortVehicleSpecificActuatorCommands IntelligentPrimitiveDriver Indirect MotionActuatorCommands Subsystem System CommandedWrenchEffortIPD Command PoseSystemQueryPose PoseData Figure 3-1: Intelligent Primitive Driver implementation

PAGE 38

27 3.1.4 IPD Input and Output Messages This section will define the set of user-defined input and output messages used by the IPD. 3.1.4.1 Set Auxiliary Actuators The Set Auxiliary Actuators message controls the indirect motion actuators available on the platform. The command consists of four available linear actuator fields and four available rotational actuator fields. Each field in the command may be mapped directly to a single actuator of corresponding type, either linear or rotational, for control. The interpretation of the numerical limits of the data fields allow for a wide array of actuator control. The limits may be interpreted as a percentage of the maximum speed to move the actuator at, a percentage of the maximum distance to move the actuator to, or even interpreted as a blind forward/reverse/stop control message. The data fields and vector-mapping table is for this command is found in Table 3-2. Table 3-2: Set Auxiliary Actuators command fields Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Mapping Table that Follows 2 Aux Actuator 1 Scaled Integer 3 Aux Actuator 2 Short Integer Percent Lower Limit: -100 4 Aux Actuator 3 Upper Limit: 100 5 Aux Actuator 4 6 Aux Actuator 5 Scaled Integer 7 Aux Actuator 6 Short Integer Radians Lower Limit: 8 Aux Actuator 7 Upper Limit: 9 Aux Actuator 8 Vector to Data Field Mapping for Presence Vector of Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field 9 8 7 6 5 4 3 2

PAGE 39

28 3.1.4.2 Query Auxiliary Actuators The Query Auxiliary Actuators message will cause the IPD to reply to the requesting component with a Report Auxiliary Actuators message. The command field is shown in Table 3-3. Table 3-3: Query Auxiliary Actuators command field Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Report Auxiliary Actuator Message 3.1.4.3 Report Auxiliary Actuators The Report Auxiliary Actuators command message provides the receiving component with the current values of the commanded Set Auxiliary Actuators message. The message data and mapping of the presence vector for the Report Auxiliary Actuators message are the same as the Set Auxiliary Actuators message, as seen in Table 3-2. 3.1.4.4 Set Behavior X The Set Behavior X message is used to initiate the behavioral control algorithms, which are to be applied to the individual platform. The message has been issued the command code range of 0xFFF2 to 0xFFF9 to allow for 8 vehicle specific behavior codes to be applied to the control system. The corresponding behavior number, from 1 to 8, replaces the X in the command code names in the code definition. The data fields are delineated into 4 unsigned integers and 4 full integers, giving the design engineer a wide range of available variables to transmit any necessary behavioral data to the system, such as latitude and longitude, heading, or distance to travel. As such, a specific behavior may

PAGE 40

29 be defined by all, some, or none of the available data fields. The data fields and vector-mapping table is for this command is found in Table 3-4. Table 3-4: Set Behavior X command fields Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Mapping Table that Follows 2 Behavioral Parameter 1 3 Behavioral Parameter 2 Unsigned Int N/A User defined fields 4 Behavioral Parameter 3 5 Behavioral Parameter 4 6 Behavioral Parameter 5 7 Behavioral Parameter 6 Float N/A User defined fields 8 Behavioral Parameter 7 9 Behavioral Parameter 8 Vector to Data Field Mapping for Presence Vector of Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field 9 8 7 6 5 4 3 2 3.1.4.5 Query Behavior X The Query Behavior X message will cause the IPD to reply to the requesting component with a Report Behavior X message. The command field is shown in Table 3-5. Table 3-5: Query Behavior X command field Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Report Behavior X Message 3.1.4.6 Report Behavior X The Report Behavior X command message provides the receiving component with the current behavioral data being performed by the platform. The message data and

PAGE 41

30 mapping of the presence vector for the Report Behavior X messages are the same as the Set Behavior X message, as seen in Table 3-4. 3.2 Intelligent Primitive Driver Application An Intelligent Primitive Driver component must be applied to a vehicle to fully define the functionality of the behavioral and auxiliary actuator controls as no vehicle specific data is given in the JAUS definition of the component. This section will discuss the four main areas that comprise the application of the IPD to the Remotec Andros test platform. These areas include: a discussion of the basis of the intelligence used in the control algorithms, the functionality of the component as it pertains to the Andros robot, an explanation of the program logic used in the controller, and an explanation of the stair motion algorithms used by the controller. 3.2.1 Fuzzy Logic Professor Lotfi Zadeh at the University of California in Berkley developed fuzzy Logic in 1965 as a method of processing data by allowing partial set membership rather than classical precise set membership or non-membership. Fuzzy Logic is based upon a human intelligence model; Professor Zadeh reasoned that people do not need precise, numerical information as input and yet they are capable of highly adaptive control. As intuitive as this approach of control may appear, it was not applied to an actual control system until the 1970s, mainly due to inadequacies in small-computer capabilities at the time [13]. Fuzzy Logic provides a simple way to arrive at a definite conclusion based upon vague, ambiguous, noisy or imprecise information. The logic model focuses on what a system should do rather than trying to understand how the system works and concentrates on the problem rather than attempting to represent the system mathematically, which may

PAGE 42

31 be impossible, especially in the case of nonlinear systems. Fuzzy Logic incorporates a simple, rule-based if X and Y then Z problem solving control approach. This approach relies upon an empirically based model, which is dependent on the design engineers control experience. The system is inherently robust as it does not require precise inputs, can be designed to fail safely if an input is lost, and despite the possible wide variation of the input signal, the output is always a smooth control signal. As the design engineer defines the rules that govern the system, the controller can easily be modified to improve or dramatically alter system performance. Finally, any sensor that presents the controller with an indication of the systems actions, regardless of sensor cost or precision, is a viable candidate for the fuzzy controller [13]. The fuzzy logic control model was applied to the four major intelligence functions of the control system: the stair protocol arbiter, the platform alignment controller, the auxiliary track controller, and the task used to realign the Andros upon the stairs after a slippage error has occurred. Each of these functions will be discussed as they are encountered in the descriptions of the control algorithms to follow. 3.2.2 Functionality To utilize the control capabilities of the Intelligent Primitive Driver, the command messages associated with the component must be completely defined to interact with the platform. The Set Auxiliary Actuators command must be mapped to control the platforms indirect motion actuators. Vehicle behaviors must be assigned a control number corresponding to one of the available Set Behavior commands, the requisite control data for the behavior must be defined and assigned to the proper command variable and the behavioral algorithms themselves must be characterized and coded for use.

PAGE 43

32 As shown in Table 3-2, the Set Auxiliary Actuators command message has eight assignable auxiliary actuators command fields. Following this convention, the front auxiliary track of the Andros robot is denoted as Aux Actuator 5 and the rear auxiliary track is denoted as Aux Actuator 6. These fields were chosen as the auxiliary tracks of the Andros may be moved to a specific angle through the use of the Auxiliary Track Position System, described in Chapter 2.3. The behavioral controls of the IPD are used to control the motion of the Andros on a set of stairs, both ascending and descending. The ascending motion behavior has been mapped to Set Behavior 1 with the descending motion mapped to Set Behavior 2. Both behaviors use the same the control data variables, which have been assigned to the data fields shown in Table 3-6. Table 3-6: Set Behavior 1 and 2 control data Field # Name Description 2 Behavioral Parameter 1 Rise of a Single Step (in.) 3 Behavioral Parameter 2 Run of a Single Step (in.) 4 Behavioral Parameter 3 Total Number of Steps 5 Behavioral Parameter 4 Not Used 6 Behavioral Parameter 5 Stair Heading (degrees) 7 Behavioral Parameter 6 Not Used 8 Behavioral Parameter 7 Not Used 9 Behavioral Parameter 8 Not Used 3.2.3 Program Logic Figure 3-2 depicts the logic flow diagram of the Intelligent Primitive Driver upon startup. This diagram is only representative of the Intelligent Primitive Driver and not the JAUS system on the whole. The receipt and execution of JAUS commands by standard components have been omitted because, for these instances, the controller

PAGE 44

33 behaves in a manner consistent with a standard JAUS controller. Upon startup of the Andros controller, the IPD enters a ready state and awaits the reception of an IPD command message. The receipt of one of these commands causes the IPD to assume control of the Andros and execute the desired commanded function. Start Controller Ready State CommandMsg Recvd?YesNo ExecuteCommand CommandCompleted? NoYes Figure 3-2: Intelligent Primitive Driver logic flow diagram Upon receipt of a Set Auxiliary Actuators command, the IPD moves into the algorithm as shown in Figure 3-3. The IPD uses the Auxiliary Track Positioning System, as outlined in Chapter 2.3, to determine the current angle of the auxiliary track. Once the current angle has been determined, the algorithm checks to see in which of three possible fuzzy sets the current track angle lies: less than the desired angle, greater than the desired angle, or around the desired angle. The IPD will determine the direction, if any, to rotate the track dependent upon which set the current track angle lies. If the current track angle

PAGE 45

34 is less than the desired track angle, the track is rotated counterclockwise. If the current track angle is greater than the desired track angle, the track is rotated clockwise. If the track angle is equal to the desired track angle, within an angular tolerance of +/-1 degree, the track is not rotated and the controller IPD returns to the ready state. The two-degree total tolerance was determined heuristically based upon the maximum update rate of the controller, the precision of the Auxiliary Track Positioning System and the overall speed of motion of the auxiliary tracks while rotating. This algorithm is followed independent of which auxiliary track is commanded to move. RecvCommand Read CurrentAux TrackAngle Current Angle Lessthen Desired Angle?Yes Rotate AuxTrack CCW Current AngleGreater then DesiredAngle?Yes Rotate AuxTrack CW Current Angle Equalto Desired Angle? Yes Task Complete NoNoNo Figure 3-3: Set Auxiliary Actuator algorithm

PAGE 46

35 Upon receipt of a Set Behavior command, the IPD executes the algorithm shown in Figure 3-4. The IPD calculates the total dimensions of the stairs from the control data received along with the command, as seen in Table 3-6. Through simple geometric equations, the IPD determines the total length, L, and pitch angle, of the stairs, as seen in Figure 3-5. Next, the IPD aligns the heading of the Andros platform with the heading of the staircase. Start Behavior Align Androswith Stairs AndrosAligned?YesNo Stair Length Lessthen Critical Length? BeginProtocol 1 BeginProtocol 2 Calculate StairDimensions Stair Length Greaterthen Critical Length? YesYesNo Start SkewAlignment Task Start StairCounter Task Figure 3-4: Opening sequence of Set Behavior X algorithm

PAGE 47

36 The align platform function is another of the fuzzy logic functions. It calculates the difference between the reported stair heading and the current heading of the Andros, obtained from the Andros onboard digital compass. The absolute value of the difference is then compared against the defined fuzzy sets. Figure 3-5: Stair data representation If the absolute value is greater than 90 degrees, the Andros is rotated at its maximum speed. If the absolute value is between 90 and 60 degrees of error, the Andros is rotated at 75% of its maximum speed. If the absolute value is between 60 and 25 degree of error, the Andros is rotated at 50% of its maximum speed. Finally, if the absolute value is less than 25 degrees, the Andros is rotated at 25% of its maximum speed. This function has an allowable angular tolerance of +/-4 degrees. The direction of the commanded rotation is also dependent upon a fuzzy interpretation of the angular difference. If the absolute value of the difference is less than 180 degrees and the actual difference is negative, the Andros is rotated counterclockwise at the desired speed. If the absolute value of the difference is less than 180 degrees and the actual difference is positive, the Andros is rotated clockwise at the desired speed. The direction of rotation relative to the actual Total Len g th Rise Total Run Total Rise Run

PAGE 48

37 value of the difference is reversed if the absolute value of the difference is found to be greater than 180 degrees. This ensures that the Andros takes the shortest route possible to reach the commanded heading. Once the Andros has been aligned, the IPD starts the skew alignment task. This is a separate program thread, which runs parallel to the main stair control thread. The purpose of the skew alignment task is to detect and counter any angular slippage of the Andros upon the staircase. Slip detection is accomplished by monitoring the difference between the current heading of the Andros and the heading of the stairs, similar to the align platform function. Figure 3-6: Skew alignment task correction Direction of Adjustment Direction of Slip If an angular slippage error is detected, the skew alignment task counters it by rotating the Andros in the direction opposite of the slippage. (Figure 3-6) This, again, is a fuzzy logic task as the slippage error is grouped into broad sets of possible angular error. If the error is greater than 5 degrees but less than 10, the Andros is rotated at 15%

PAGE 49

38 of its maximum speed. If the error is between 10 and 25 degrees, the Andros is rotated at 25% of its maximum speed. At greater than 25 degrees, the error begins to approach a non-recoverable state, and the Andros is stopped so that appropriate measures can be taken to safely move it off of the staircase. Once the heading error is less than the 6 degrees of angular tolerance, the Andros rotation is halted. The linear motion control command of the Andros is never affected by the skew alignment task, except for the case in which the error is greater than 25 degrees, as the Andros embedded controller allows for both linear and rotational motion components to be commanded at the same time. After the skew alignment task has been spawned, the IPD begins the stair counter task. The stair counter task uses the stair counter assembly, as described in chapter 2.3, to count the number of steps the Andros has successfully passed and also to account for any possible linear slippage error. The number of steps must be counted to provide the IPD with the relative position of the Andros upon the staircase to trigger stair motion events, such as auxiliary track motions. The next step for the IPD to complete is to determine which stair protocol should be evoked. This is accomplished by determining if the total length, L, of the staircase is less than or greater than the critical length. The critical length is defined as 1.5 times the total length of the Andros. If the total length is less than the critical length, protocol 1 is chosen. If the total length is greater than the critical length, protocol 2 is chosen. The reason for the demarcation between the two protocols is simple: a staircase with a total length equal to or less than the critical length simply does not have enough available length to adequately carry out the full range of stair climbing motions. Also, the majority of the stair motions are meant to ensure that the Andros is stable upon the staircase and

PAGE 50

39 that the tracks do not lose traction. This is not a concern on short staircases as it is on longer ones. It should be noted that the portion of the stair motion algorithm, as seen in Figure 3-4, is the same for both the ascend and the descend behavior commands. Also independent of the direction of travel upon the stairs is the protocol arbiter. Protocol 1 is designated for control of the Andros on a set of stairs less than the critical length in both the ascend and descend commands, protocol 2 corresponds to control of the Andros on a set of stairs longer than the critical length in both the ascend and descend commands. Once the stair protocol has been carried out, the controller reverts back to its ready state and awaits further commands from the System Commander. 3.2.4 Ascend Protocol 1 This stair motion protocol deals with the situation in which the total length of the staircase is less than the critical length. First, the front auxiliary tracks of the Andros are aligned with the angle of the stairs, (Figure 3-7a) Then, the Andros is simply started up the staircase. The protocol concludes as the Andros passes the last step of the staircase and is safely situated on the top landing, as seen in Figure 3-7c. 3.2.5 Ascend Protocol 2 The second ascend stair motion protocol deals with the situation where the total length of the staircase is longer than the critical length. In this situation, the full range of control steps are necessary to ensure that the Andros makes it safely to the top of the staircase. The first stage of the process is to align the front auxiliary tracks of the Andros with the angle of the stairs, and the rear auxiliary tracks parallel to the ground. (Figure 3-7a) This stage occurs while the Andros is preparing to climb the staircase, therefore

PAGE 51

40 there are no steps associated with it. In the next stage, the Andros is started up the staircase. After two steps have passed, the front auxiliary tracks are aligned parallel with the line of the stairs, as seen in Figure 3-7b. The Andros continues on in this third stage alignment until the last step of the staircase is reached. As this step is reached, the last stage is initiated. The front auxiliary tracks of the Andros are moved downward to catch the Andros as it passes the apex of the stairs. This can be seen in Figure 3-7c. Figure 3-7: Ascend stair motion protocol: a) Align front auxiliary tracks with stair angle; b) Andros moving on stairs; c) Andros moving over apex of stairs c) b) a)

PAGE 52

41 3.2.6 Descend Protocol 1 As with ascend protocol 1, descend protocol 1 is evoked when the total length of the staircase to be traversed is less than the critical length. The Andros is moved to the edge of the staircase and the front auxiliary tracks are moved downward to catch the Andros as it crosses the apex of the stairs, as seen in Figure 3-8a. Next, the Andros is simply driven over the edge of the steps and the front auxiliary tracks are moved parallel to the ground plane. Once the Andros has reached the floor level, it is moved away from the staircase. Figure 3-8: Descend stair motion protocol: a) front auxiliary track moved to catch Andros; b) rear auxiliary track moved to push Andros over apex; c) align front auxiliary track with stairs; d) front auxiliary tracks moved to catch Andros at stair landing a) b) c) d)

PAGE 53

42 3.2.7 Descend Protocol 2 Descend protocol 2 occurs when the total length of the staircase to be traversed down is longer than the critical length. The Andros is moved to the edge of the stairs and the front auxiliary tracks are moved downward to catch the Andros as it crosses the apex of the stairs. (Figure 3-8a) While this is occurring, the rear auxiliary tracks are moved downward to help rotate the Andros down to the plane of the staircase. (Figure 3-8b) The Andros is moved forward until the main tracks come in contact with the stairs, as seen in Figure 3-8c. The controller uses the end of world capability of the stair counter assembly to determine the edge of the stairs, as discussed in Chapter 2.3. The Andros is moved further forward and rear auxiliary tracks are moved to a horizontal position. The Andros is moved down the steps until the third to last step is reached. Then, the front auxiliary tracks are moved to parallel to the ground plane, which allows the Andros to make an easy transition to the plane of the floor. (Figure 3-8d) The Andros is then moved off and away from the staircase.

PAGE 54

CHAPTER 4 TESTING AND RESULTS This chapter describes the testing of the individual subsystems associated with the Andros Intelligent Primitive Driver (IPD). Testing procedures and results will be reported for the stair-counter assembly, the auxiliary track positioning system and the heading alignment controller. 4.1 Stair-Counter Assembly 4.1.1 Testing Procedure The stair counter assembly was tested to ascertain whether or not the concept would accurately count the number of stairs the platform has passed and therefore, be a viable addition to the positioning system. The first step to accomplish this task was to calibrate the infrared sensors that the system uses. This was done to correlate the values returned from the analog-to-digital converter (ADC), which are used to interface the Sharp GP2D12 infrared object detectors and the Rabbit RCM3200 microcontroller, to their corresponding distances. To do this, a target was first placed a known distance away from the infrared sensor. Then, one hundred readings of the value returned from the infrared sensor through the ADC were recorded and their average obtained. The target was then moved to another known distance and the average value was again found. This process was repeated for distances measuring 4, 6, 8, 10, 12, 14 inches. The data points were plotted using Excel and several regression curves were applied to determine which type best fit the data. It was determined that the non-linear power function shown in 43

PAGE 55

44 Figure 4-1 best described the output. The equation shown was then used in the code to convert the ADC readings to distances for the testing. y = 496.6x-0.9R2 = 0.9974020406080100120140160024681012141Distance (in)ADC Value 6 Figure 4-1: Calibration data for Sharp GP2D12 infrared object detectors Once the infrared sensor had been calibrated, a method of gathering the test data from the staircase needed to be devised. To accomplish this, a testing frame made from 80/20 extruded aluminum framing system was constructed. The 80/20 was chosen for this task as it was easily assembled and the extruded grooves were ideal for constraining the motion of the test sled along the major axis of the stairs. The test sled housed the Rabbit microcontroller as well as one of the Sharp GP2D12 infrared object detectors to acquire the range data. The sled was then tethered to a 12-volt gear motor to pull it along at a

PAGE 56

45 relatively constant velocity. The entire assembly was placed upon the stairs, as seen in Figure 4-2. Figure 4-2: Stair-counter testing assembly The system recorded a reading of the range data from the surface of the staircase to the infrared sensor once every 50 milliseconds. This delay was chosen, as it is longer than the 32-millisecond update rate of the infrared sensors and therefore ensured that no duplicate readings were accidentally recorded by the system. The microcontroller then determined the first derivative of the data, applied a three element median filter to it, and then determined the second derivative. A Dell Inspiron 8100 laptop computer then recorded this data set. Communication between the Dell and the Rabbit were made via the 57.6-kBaud connection provided for diagnostic purposes by the microcontroller. The test was run a total of ten times on two separate staircases. The stair-counter testing also had a secondary purpose: to empirically determine a second derivative threshold value for the stair-counter control code. The stair-counter

PAGE 57

46 code uses the second derivative values to determine if a stair has been passed and should therefore be counted. However, detecting a single second derivative value for this purpose is futile; a range of second derivative values that correspond to a stair edge may be encountered. The system may also experience subtle negative second derivative peaks due to uneven motion of the Andros upon the stairs. To account for all of this, the second derivative value is compared to a threshold value. If the value is less than the threshold, it is determined to be a stair edge and is counted. 4.1.2 Results The data collected from the stair-counter testing rig was placed into an Excel spreadsheet for graphing purposes. The data was analyzed to determine when the second derivative of the stair representation occurred with respect to the recorded inflection point, or outside edge, of the stairs. Figure 4-3a illustrates the first set of sample data from the acquired from the testing. The dark blue line represents the detected outline of the staircase, while the red line represents the calculated second derivative of this data. Clearly visible are the two large negative impulses, each one corresponding to one of the stair peaks shown. As designed, each impulse is logged 0.25 seconds after the stair peak is experienced. The same is true of Figures 4-3b and 4-3c; each one has two large, negative impulses that occur 0.25 seconds after their corresponding stair peaks are detected. Also, in each of these figures, the negative impulses are less than .2, while none of the tertiary negative impulses approach this value. Therefore, this was determined to be the optimum threshold value for the system to use.

PAGE 58

47 b) Stair Data Representation and 2nd Derivative Data, Sample 2012345678910012345678910111213141516Time (sec)Distance (in)-1-0.8-0.6-0.4-0.200.20.40.60.81 Stair Data 2nd Derivative a) Stair Data Representation and 2nd Derivative Data, Sample101234567891001234567891011121314151617Time (Sec)Distance (In)-1-0.8-0.6-0.4-0.200.20.40.60.81 Stair Data 2nd Derivative c) Stair Data Representation and 2nd Derivative Data, Sample 30123456789100123456789101112131415Time (sec)Distance (in)-1-0.8-0.6-0.4-0.200.20.40.60.81 Stair Data 2nd Derivative Figure 4-3: Stair-counter data: a) sample 1, b) sample 2, c) sample 3

PAGE 59

48 4.2 Auxiliary Track Positioning System 4.2.1 Testing Procedure The setup for the auxiliary track positioning system testing had two steps. First, the maximum and minimum values returned to the system by the Draw Wire Transducer (DWT) were obtained. These values are used in conjunction with Equation 2-1 to convert the measured DWT value to an angular measurement. The maximum value occurs when the auxiliary track has been rotated to its topmost point, while the minimum value occurs when the auxiliary track has been rotated to its bottommost point; these points correspond to 150 degrees and 0 degrees, respectively. At each of these two points, one hundred values of the DWT were taken and then an average value was obtained. Figure 4-4: Plumb compass attached to Andros auxiliary track

PAGE 60

49 The second step in the setup was to affix a plumb compass to the auxiliary track so that an independent angle measurement of the position of the track could be made. A plumb compass is comprised of a needle, weighted at the bottom, along with an adjustable faceplate. By attaching the body of the plumb compass to a structure, the relative angle of the structure with respect to ground may be found when the structure is rotated. The Andros auxiliary tracks were rotated to their bottommost point and the adjustable face of the plumb compass was then adjusted such that the compass needle pointed to 0 degrees. In this configuration, the compass needle pointed to 150 degrees when the auxiliary tracks were rotated to their topmost position, which corresponds to the measurement convention utilized by the controller. Figure 4-4 illustrates the plumb compass attached to the Andros auxiliary track. To test the commands for the auxiliary track positioning system, the Operator Control Unit (OCU) was used to send the experimental JAUS message, Set Auxiliary Actuators, to the Andros JAUS controller, along with a commanded angular position of the auxiliary track. The initial set of commanded angles were used to determine the minimum allowable tolerance that could be used by the system without the system becoming unstable. In this case, the system would be unstable if the controller continually reversed the direction of the auxiliary track in an attempt to move the track to the desired angle and be within the given tolerance. The minimum allowable tolerance for the system was found to be +/1 degree. Following this, another set of Set Auxiliary Actuators commands were sent to the system and the commanded angle, the angle returned by the DWT sensor, and the angle read off of the plumb compass were recorded.

PAGE 61

50 4.2.2 Results Figure 4-5 shows a plot of the controller commanded halt angle and the actuator halt angle versus the commanded angle sent to the controller from the OCU. The controller commanded halt angle is the angle returned to the controller from the DWT sensor at the instant that the controller issued the halt rotation command. The actuator halt angle is the angle read from the plumb compass and corresponds to the angle of the auxiliary track after the rotation has actually stopped. Both sets of data points have a linear distribution across the entirety of the available range of motion, as illustrated by the applied trend lines and their respective R 2 values. The controller commanded halt angle and the actuator halt angle are identical at 0 degrees and 150 degrees because there are physical stops at these points of rotation on the Andros frame. y = 1.0.x 1.6R2 = 0.9921y = 1.0x + 0.4R2 = 0.999801020304050607080901001101201301401500102030405060708090100110120130140150Commanded Angle (Degrees)Angle (Degrees) Actuator Halt Angle Controller Commanded Halt Angle Actuator Halt Angle Controller Commanded Halt Angle Figure 4-5: Controller commanded halt angle and actuator halt angle versus operator commanded angle

PAGE 62

51 Figure 4-6 depicts a plot of the error between the commanded angle sent from the OCU and the controller commanded halt error and the actuator halt angle. The controller commanded halt error is the error between the commanded angle and the auxiliary track angle at the instant that the controller issued the halt command and is recorded from the DWT sensor. The actuator halt error is the error between the commanded angle and the auxiliary track angle after the track actually stops and is recorded from the plumb compass. The average error value returned from the DWT sensor is 0.5 degrees with a standard deviation of 0.3, whereas the average error value returned from the plumb compass is 3.4 degrees with a standard deviation of 2.2. Figure 4-6: Controller commanded halt error and actuator halt error versus operator commanded angle -9.0-8.0-7.0-6.0-5.0-4.0-3.0-2.0-1.00.01.02.03.04.05.06.07.08.0 9 0 0102030405060708090100110120130140150Commanded An g le ( De g rees ) Error (Degrees) Controller Commanded Halt Angle Error Actuator Halt Angle Error

PAGE 63

52 4.3 Heading Alignment Controller 4.3.1 Testing Procedure The first step necessary to test the heading alignment controller was to calibrate the PNI Corporation TCM2-20 digital compass. A serial connection was established between the digital compass and a Dell Inspiron 8100 laptop computer and the digital compass was placed into polling mode. Then, the compass was given the command to start its calibration cycle and the Andros was slowly rotated in a circle for approximately four minutes. Once this was completed, a series of Set Behavior 1 commands were sent from the OCU to the Andros JAUS controller, along with the desired heading. The JAUS controller was coded such that the Set Behavior 1 command initiated the heading alignment code. The first series of tests were administered to determine the minimum allowable tolerance value that the system could accept without the system becoming unstable. In this situation, the system would be unstable if the controller continually reversed the rotation of the Andros in an attempt to move the Andros to the desired heading. From these initial tests, the allowable tolerance for the system was found to be +/4 degrees. After this was completed, another set of Set Behavior 1 commands were sent from the OCU and the commanded heading, compass heading, and final Andros heading were recorded. The compass heading is the value that the digital compass last reported to the controller to illicit a stop rotation command. The final Andros heading is the compass measure of the heading of the Andros when the rotation actually stops. 4.3.2 Results Figure 4-7 depicts a plot of the controller commanded halt heading and the vehicle halt heading versus the desired heading sent from the OCU. The controller commanded halt heading is the heading returned to the controller at the instant that the controller

PAGE 64

53 issues a stop vehicle rotation command. The vehicle halt heading is the heading of the vehicle when the vehicle actually stopped its rotation. Both sets of data have a linear distribution across the entire range of rotation, as illustrated by the applied trend lines and their respective R 2 values. y = 1.0x 3.2R2 = 0.9967y = 0.9x + 2.2R2 = 0.9992020406080100120140160180200220240260280300320340360020406080100120140160180200220240260280300320340360Desired Heading (Degrees)Heading (Degrees) Vehicle Halt Heading Controller Commanded Heading Vehicle Halt Heading Controller Commanded Heading Figure 4-7: Controller commanded halt heading and vehicle halt heading versus operator commanded heading Figure 4-8 depicts a plot of the controller commanded heading error and the vehicle heading error versus the desired heading sent from the OCU. The controller commanded heading error is the error between the desired heading and the heading of the vehicle when the controller issues a stop rotation command. The vehicle heading error is the error between the desired heading and the heading of the vehicle when its rotation is actually stopped. The average error value for the controller heading is 2.8 degrees with a

PAGE 65

54 standard deviation of 0.8, whereas the average error value for the final Andros heading is 5.9 degrees with a standard deviation of 1.7. -10-9-8-7-6-5-4-3-2-1012345678910060120180240300360Heading (Degrees)Error (Degrees) Vehicle Heading Error Controller Commanded Heading Error Figure 4-8: Controller commanded heading error and vehicle heading error versus operator commanded heading

PAGE 66

CHAPTER 5 CONCLUSIONS AND FUTURE WORK 5.1 Conclusions This research focused on the development of the Intelligent Primitive Driver (IPD), an experimental, low-level, intelligence component for the Joint Architecture for Unmanned Systems (JAUS). Three objectives were necessary to accomplish this task. First, the IPD had to meet the criteria of a fully defined, standard JAUS component. Second, a testing platform had to made JAUS compliant and the functionality of the IPD had to be applied to the testing platform. Finally, the intelligence components of the IPD that were applied to the testing platform had to be tested. A standard JAUS component is defined through four criteria: the function of the component, the accepted input and output messages that the component may handle, and the full description of the component. In these terms, the IPD was fully constrained to the JAUS architecture. The purpose was defined as being responsible for the control of all indirect motion related actuators. A full set of input and output messages were defined to meet the JAUS message standards. The component description defined the implementation of the IPD into the JAUS architecture, set the IPDs unique component identification number at 99, and discussed the specifics of the IPDs functionality. A Remotec Andros robot was chosen as the testing platform because of the indirect motion actuators located on the chassis and its complicated behavioral controls, namely stair-climbing. A complete JAUS controller was developed specifically to be used by the 55

PAGE 67

56 Andros platform; an Operator Control Unit (OCU), Primitive Driver, Node Manager, Position System and Communicator components were coded for both the Rabbit RCM3200 microcontroller with the Dynamic C operating system and the Gateway Solo 3350 laptop with the Linux Redhat 8.0 operating system. The Rabbit was used as the Andros JAUS controller, while the Solo 3350 was used as the OCU. The Intelligent Primitive Driver was applied to the Andros platform: the IPDs capability to control indirect motion actuators were mapped to the auxiliary tracks of the Andros and the behavioral control commands were mapped to the stair ascending and descending procedures. The proprietary Andros control stream was reverse engineered from the native Andros controller and then applied to the Primitive Driver and Intelligent Primitive Driver. As such, the Andros JAUS controller was able to accept and interpret JAUS commands and incite the Andros to act upon these commands accordingly. The controller, as mounted on the Andros platform, can be seen in Figure 5-1. Figure 5-1: Controller mounted on Andros platform

PAGE 68

57 The intelligence components of the Intelligent Primitive Driver were tested to ensure that they adequately performed the desired control function. A testing frame was constructed to constrain the motion of a sled housing one of the Sharp GP2D12 infrared object detectors so that the stair-counter assembly could be tested. From the data gathered from the system, it was shown that the negative second derivative impulses could be observed by the system and that they did indeed lag the detection of the outside stair edge by 0.25 seconds, as designed. The auxiliary track positioning system was tested to determine if the final angular placement of the auxiliary tracks coincided with the desired angular command. It was found that the average error value for the controller commanded halt angle was 0.5 degrees with a standard deviation of 0.3, whereas the average error value for the actual auxiliary actuator position was 3.4 degrees with a standard deviation of 2.2. The minimum allowable tolerance for this control system was +/1 degree. The heading alignment controller was tested to determine if the final heading of the Andros coincided with the desired heading command. It was found that the average error value for the controller commanded halt heading was 2.8 degrees with a standard deviation of 0.8, whereas the average error value for the actual halt heading of the Andros was 5.9 degrees with a standard deviation of 1.7. The minimum allowable tolerance for this control system was +/4 degrees. Both of these control systems performed as designed and returned favorable data when the limitations inherent to the Andros platform were taken into account. The discrepancies between the DWT and plumb compass error in the auxiliary track positioning system and the final heading and compass heading error in the heading alignment controller are a direct manifestation of the limitations of the Andros system.

PAGE 69

58 As discussed in Chapter 2, the maximum update rate of the Andros control stream is 5 Hz. In terms of autonomous computer controllers, 0.2 seconds is a relatively long amount of time. In both the auxiliary track positioning system and the heading alignment controller tests, the controller commanded a halt of system motion that was not acted upon until at least 0.2 seconds later. This fact translated into an average difference of 2.9 degrees for the auxiliary track positioning system and an average difference of 3.1 degrees for the heading alignment controller. Therefore, when the controller believes it has reached the desired command position and has thus stopped the motion of the Andros, the Andros is in actuality continuing to move. It is for this reason that the Andros stair motion behavior has been broken down into its component parts and these parts have been tested individually, instead of simply testing the Andros stair motion controller in its entirety; it is entirely within the realm of possibility that the Andros would incur a non-recoverable, fatal error when attempting to negotiate a staircase even though the controller recognized the error and attempted to correct it. The Andros is able to negotiate a set of stairs when controlled by a human operator with a more reasonable expectation of a successful conclusion than with the JAUS controller for two reasons, though it is still a very difficult and complicated task. First, in terms of human control, 0.2 seconds is a relatively long amount of time. Second, the human operator has both control experience and predicate knowledge of the system. Therefore, the human operator can make predictive assumptions concerning the stair motion process that the JAUS controller is unable to make. For example, the human operator can take into account the type of stair to be traveled upon, the condition of the Andros tracks, and the amount of traction that the Andros is exhibiting when actually on

PAGE 70

59 the stairs to make corrections to the stair motion process. With this incarnation of the IPD, these predictive capabilities are not present. 5.2 Future Work To increase the controllability of the Andros-IPD system, upgrades need to be made to several of the subsystems. First, and most importantly, the Andros embedded controller should be updated to a more modern control scheme. The outdated controller and its 1200-Baud connection should be replaced by a modern microcontroller utilizing a secure Ethernet connection protocol, such as the Transmission Control Protocol (TCP). This replacement would solve the control problems, which currently inhibit the system. When making this update, the current drive motors and auxiliary track positioning motors should be replaced with motors that have integrated rotary encoders. This would serve two purposes. First, the encoders located on the driver motors could be utilized to add dead-reckoning capability to the current position system. With this, specific information concerning the total movement of each individual track could be collected and used for more exact vehicle placement. Second, the encoders on the auxiliary track positioning motors could replace the Draw Wire Transducers (DWT) currently used to acquire auxiliary track position. The DWT sensors work very well, but are susceptible to environmental conditions and hazards; the internal encoders would not have this potential problem. The Intelligent Primitive Driver should be modified to include adaptive control capabilities to the stair motion algorithms. Concepts of neural networks could be applied to the controller to give it the ability to learn from stair motion trials. This would allow the system to adapt the stair motion algorithms to work more efficiently on different types of stairs. For example, the controller could determine if an auxiliary track should

PAGE 71

60 be moved at a different point during the stair motion algorithm or change the correction speeds used to correct the Andros if it slips on the staircase. Finally, the Intelligent Primitive Driver should be applied to other JAUS compliant platforms and further application testing should be performed. In doing this, the viability of the component could be completely explored and documented. After this, the component could be presented to the Working Group of the Joint Architecture for Autonomous Systems (JAUS) for the formal inclusion of the IPD into the Reference Architecture.

PAGE 72

APPENDIX A STANDARD JAUS MESSAGES This Appendix contains information pertaining to the Set Wrench Effort and Query Global Pose standard JAUS messages, as well as a list of the core JAUS message set. A.1 Query Global Pose The command code for this message is defined as 0x2402 and causes the receiving component to respond with a Report Global Pose message. Table A-1 depicts the data field assignments for the Query Global Pose message [10]. Table A-1: Query Global Pose data field (used from JAUS: Reference Architecture Specification, pg. 93) Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See Report Global Pose Message A.2 Set Wrench Effort The command code for this message is defined as 0x0405 and controls platform mobility actuators by mapping the six propulsive and six resistive elements that comprise a wrench command to the mobility actuators of a vehicle. Table A-2 depicts the data field assignments for the Set Wrench Effort message [10]. 61

PAGE 73

62 Table A-2: Set Wrench Effort data fields (from JAUS: Reference Architecture Specification, pg. 80) Field # Name Type Units Interpretation 1 Presence Vector Unsigned Short N/A See mapping table that follows. 2 Propulsive Linear Effort X 3 Propulsive Linear Effort Y 4 Propulsive Linear Effort Z 5 Propulsive Rotational Effort X 6 Propulsive Rotational Effort Y 7 Propulsive Rotational Effort Z Short Integer Percent Scaled Integer Lower Limit = -100 Upper Limit = 100 8 Resistive Linear Effort X 9 Resistive Linear Effort Y 10 Resistive Linear Effort Z 11 Resistive Rotational Effort X 12 Resistive Rotational Effort Y 13 Resistive Rotational Effort Z Byte Percent Scaled Integer Lower Limit = 0 Upper Limit = 100 Vector to Data Field Mapping for Above Command Vector Bit 15 14 13 12 11 10 9 8 Data Field R R R R 13 12 11 10 Vector Bit 7 6 5 4 3 2 1 0 Data Field 9 8 7 6 5 4 3 2 R indicates that the bit is reserved.

PAGE 74

63 A.3 JAUS Core Message Set Table A-3 shows the core set of JAUS messages and their corresponding command codes [10]. Table A-3: JAUS core message set Code Description 0x01 Set Component Authority 0x02 Shutdown 0x03 Standby 0x04 Resume 0x05 Reset 0x06 Set Emergency 0x07 Clear Emergency 0x08 Create Service Connection 0x09 Confirm Service Connection 0x0A Activate Service Connection 0x0B Suspend Service Connection 0x0C Terminate Service Connection 0x0D Request Component Control 0x0E Release Component Control 0x0F Confirm Component Control 0x10 Reject Component Control

PAGE 75

APPENDIX B STAIR COUNTER MATHEMATICAL DEVELOPMENT The ability to count the number of steps the Andros has passed is critical to the ability of the Intelligent Primitive Driver to perform its designed task. As discussed in Chapter 3, the current location on the stairs of the Andros is used to trigger controlled events during the stair climbing procedure. To ensure that this was done as accurately as possible, the optimum deployment angle for the infrared sensors needed to be determined so that the stair peaks and their corresponding second derivative impulses were easily observable by the system. Figure B-1: Stair representation 64 offset run rise YXSensor Line of Action

PAGE 76

65 The stair representation used for this development has been drawn relative to the plane of motion of the Andros, as shown in Figure B-1. This reference frame is appropriate as the sensor array moves along a path parallel to the plane of motion of the Andros and the measured distances are relative to this plane, and not to the ground plane. The single stair representation shown is defined by its rise, run, and the angle, which is determined through basic geometry and is constructed of two lines that are perpendicular to each other at their single point of intersection. As the stair representation is constructed of two linear equations, one for the rise and one for the run, two separate equations for the distance, d, must be developed. The distance, d, is the range distance measured from the infrared sensor to the profile of the stair. Figure B-2: Stair runner model a f d (xo,yo)(x,y)Y X Stair Runner

PAGE 77

66 Figure B-2 shows the model used for the development of the equation for the distance, d, as it applies to runner of the stair. The first step in determining d is to find the point of intersection between the stair runner linear equation and the line of action of the sensor, (x 0 y 0 ). As the y-axis component of this point is constrained to be at y 0 x 0 can easily be found by solving the equation of the line. Using this as the point of origin, the distance, a, can be found to the point (x,y), which corresponds to the current location of the sensor. This distance is given as: 2020yyxxa (B-1) Now that the distance, a, has been acquired, the perpendicular distance, f, can be found by the equation: sinaf (B-2) Through the similar triangles concept, the angle, is shown on the two locations of Figure B-2. The angle, is the user-defined angle of the infrared sensor. Therefore, the intermediate angle, may be found, which then leads to the angle, by the equation: 90 (B-3) The distance, d, is now simply: cosfd (B-4) Figure B-3 shows the model used for the development of the equation for the distance, d, as it applies to riser of the stair. Again, the first step is to find the point of intersection, (x 0 y 0 ), between the stair riser linear equation and the line of action of the sensor. Again, as the y-axis value is constrained to be y 0 x 0 can be found by solving the

PAGE 78

67 equation of the line. Using this as the point of origin, the distance, a, can be found to the point (x,y), which corresponds to the current location of the sensor. Figure B-3: Stair riser model The equation for this distance is shown in Equation B-1. Through the similar triangles concept, the angle, is shown on the two locations of Figure B-3. The angle, is the user-defined angle of the infrared sensor. Using and the angle, may now be found by: (B-5) a d f (xo,yo)(x,y) Stair Riser X The distance, f, is defined as: cosaf (B-6) Finally, the distance, d, may be found by: cosfd (B-7)

PAGE 79

68 The two equations for the distance, d, and the stair data representation were placed into an Excel spreadsheet for analysis. From this, Figure B-4 was obtained. As shown in the figure, if the user-defined sensor angle, is less than 90 degrees relative to the line of action of the sensors, the stair edge is skewed to the left and the risers are more pronounced over the range of the stair data. If is greater than 90 degrees to the line of action of the sensors, the stair edge is skewed to the right and the runners are more pronounced over the range of the stair data. Therefore, it was determined that should be 90 degrees, or perpendicular to the line of action of the sensors, as this case is neutral and shows no preference to either the risers or to the runners of the stair data. As the stair edges are more pronounced in the neutral case, so to will the second derivative impulses be more pronounced and more easily observed by the system. 024681012141618012345678910111213141516Distance (in)Distance (in) Figure B-4: Calculated distances, d, for varying value of

PAGE 80

LIST OF REFERENCES [1] Bayouth, M., Nourbakhsh, I., and Thorpe, C., "A Hybrid Human-Computer Autonomous Vehicle Architecture," Third ECPD International Conference on Advanced Robotics, Intelligent Automation and Control, 1997. [2] Mustererkennung und Szenenanalyse (MESA) Research Group, 2003, Semi-Autonomous Driving: Intelligent Cruise Control, MESA Research Group, http://www.neuroinformatik.ruhrunibochum.de/PROJECTS/PATREC/projects/DAS/sadicc/sadicc_d.html Feb 2003. [3] Schlegel, N.,1997, Autonomous Vehicle Control Using Image Processing, Virginia Polytechnic Institute and State University, http://scholar.lib.vt.edu/theses/public/ etd-283421290973280/etd.pdf Feb 2003. [4] Connell, J. and Viola, P., Cooperative Control of a Semi-Autonomous Mobile Robot, Proc. of the 1990 IEEE International Conf. on Robotics and Automation (ICRA-90), 1990, pp. 1118-1121. [5] Huntsberger, T., and Rose, J., "Behavior-based control for autonomous mobile robots," ROBOTICS2000, Albuquerque, NM, Mar 2000, pp. 299-305. [6] Matthies, L., Xiong, Y., Hogg, R., Zhu, D., Rankin, A., Kennedy, B., Hebert, M., Maclachlan, R., Won, C., Frost, T., Sukhatme, G., McHenry, M., and Goldberg, S., A Portable, Autonomous, Urban Reconnaissance Robot, The 6th International Conference on Intelligent Autonomous Systems, Venice, Italy, July 2000. [7] Lewis, M., and Simo, L.Certain Principles of Biomorphic Robots, Autonomous Robots, volume 11, 2001, pp. 221-226. [8] Talebi, S., M. Buehler, M., and Papadopoulos, E., "Towards Dynamic Step Climbing for a Quadruped Robot with Compliant Legs," Proceedings of the 3rd International Conference on Climbing and Walking Robots, Madrid, Spain, October 2000. [9] Lauria, M., Piguet, Y. and Siegwart, R. Octopus An Autonomous Wheeled Climbing Robot, In Proceedings of the Fifth International Conference on Climbing and Walking Robots. Published by Professional Engineering Publishing Limited, Bury St Edmunds and London, UK, 2002. 69

PAGE 81

70 [10] JAUS Working Group, 2002, Joint Architecture for Unmanned Systems (JAUS): Reference Architecture Specification, Version 3.0, Volume 2, The Joint Architecture for Unmanned Systems, http://www.jaugs.org Feb 2003. [11] Operations and Maintenance Manual for Andros Mark VI Robot System, Remotec, Inc., Oak Ridge, TN., (2001). [12] Bock, R., 1998, The Data Analysis BriefBook: Median Filter, Forschungszentrum Juelich, http://ikpe1101.ikp.kfajuelich.de/briefbook_data_analysis/node168.html June 2003. [13] Tanaka, K., An Introduction to Fuzzy Logic for Practical Applications, Springer, New York, New York, (1997).

PAGE 82

BIOGRAPHICAL SKETCH Peter M. Vinch, Jr. was born on October 29, 1976 in Lawrenceville, New Jersey to Peter and Nancy Vinch, Sr. He received his Bachelor of Science degree in mechanical engineering, graduating with honors, from the Rochester Institute of Technology in May of 2000. In August of 2000, he enrolled at the University of Florida and entered the masters program in the Department of Mechanical and Aerospace Engineering. Upon graduation from the University of Florida, he plans to work in the area of autonomous vehicle development. 71

PAGE 83

University of Florida Graduate School Electronic Thesis and Dissertation (ETD) Rights and Permission 1. Enter and submit on line. 2. Print, sign, and submit to Graduate School Editorial Office Student Name: ____________________________________________________________ ID#: ____________________________________________________________ Document Type: ________Masters Thesis ________Doctoral Dissertation Document Title: Student Agreement: I hereby certify that I have obtained all necessary permission in writing for copyrighted material to be published in my thesis or dissertation. Further, I certify that I have obtained and attached hereto a written permission statement from the owner(s) of any copyrighted matter to be included in my thesis or dissertation, allowing distribution as specified below. Copies of all such permissions are maintained in my files. I hereby grant to the University of Florida and its employees the nonexclusive license to archive and make accessible, under the conditions specified below, my thesis or dissertation in whole or in part in all forms of media, now or hereafter known. This is a license rather than assignments, and I, therefore, retain all other ownership rights to the copyright of the thesis or dissertation. I also retain the right to use in future works (such as articles or books) all or part of this thesis or dissertation. In addition to the unrestricted display of the bibliographic information and the abstract, I agree that the above mentioned document be placed in the ETD archive with the following status (choose one of 1, 2, or 3) by checking the appropriate space below): ___ 1. Release the entire work immediately for access worldwide. ___ 2. Restrict access to the entire work to the University of Florida and all patrons of its libraries, including interlibrary sharing and release of doctoral dissertations to UMI. [Please check appropriate time span.] After (__1, __2, __3, __4, __5, __10) years release my work worldwide unless you receive in writing a request from me to continue restricted access. If I choose to release the work for worldwide access sooner, I will contact Library Archives, P.O. Box 117007, University of Florida, Gainesville, FL 32611. ___ 3. Secure the entire work for patent and/or proprietary purposes for a period of six months. During this period the copyright owner also agrees not to exercise her/his ownership rights, including public use in works, without prior authorization from the University of Florida. At the end of the six-month period, either I or the University of Florida may request an extension for an additional six months. At the end of the six-month secure period (or its extension, if such is requested), the work will be handled under option 1 above, unless I request option 2 in writing. The undersigned agrees to abide by the statements above, and agrees that this approval form updates any and all previous approval forms submitted heretofore. Signed: ______________________________________ ___________________ (Student) (Date) ______________________________________ ___________________ (Chair) (Date)

PAGE 84

University of Florida Graduate School Electronic Thesis and Dissertation (ETD) Signature Page Student's Name: ____________________________________________________________ This document has been reviewed and accepted by the student's supervisory committee. Professors name & title including department Professors signature ____________________________Chair ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ ________________________________ ____________________________________ Month and Year of Graduation: ____________________________________ College Dean: ____________________________________ (when required by college) Graduate Dean: ____________________________________