Copyright by Benjamin Jarrett Ebersole 2016

Copyright

by

Benjamin Jarrett Ebersole

2016

The Thesis Committee for Benjamin Jarrett Ebersole

Certifies that this is the approved version of the following thesis:

Skid-Steer Kinematics for Dual-Arm Mobile Manipulator System with

Dynamic Center of Gravity

APPROVED BY

SUPERVISING COMMITTEE:

Sheldon Landsberger

Mitchell Pryor

Supervisor:

Co-Supervisor:



by

Benjamin Jarrett Ebersole, B.S.

Thesis

Presented to the Faculty of the Graduate School of

The University of Texas at Austin

in Partial Fulfillment

of the Requirements

for the Degree of

Master of Science in Engineering

The University of Texas at Austin

December 2016

iv

Acknowledgements

I would like to thank my family, for their unconditional love and support over all

the years. I’d also like to thank my roommate and colleague Adam for being a patient and

wise sounding board for a never-ending stream of thoughts, questions, and word and

template formatting issues. And to my partner-in-crime on the VaultBot system, Andrew,

for helping to wrestle through all the amusing and frustrating quirks and oddities a robotic

system of that magnitude has to offer.

I am exceptionally grateful for my advisor Mitch Pryor’s support, guidance, and

technical advice throughout my time in the program. Sincere thanks also goes out to

Sheldon Landsberger for his fervent support of our program over the years. Thanks to Los

Alamos National Laboratories and the MET-2 division for their staunch financial and

organizational support for our program, and the excellent career opportunities they provide.

Finally, to all the members of the Nuclear and Applied Robotics Group for creating such a

fun and fascinating lab environment with a wealth of intellectual resources.

v

Abstract



Benjamin Jarrett Ebersole, M.S.E

The University of Texas at Austin, 2016

Supervisor: Sheldon Landsberger

Co-Supervisor: Mitchell Pryor

Skid-steer mobile vehicles bridge an important operational gap in robotics between indoor-

only and outdoor-only platforms. Traditionally, skid-steer vehicles have been treated and

operated as differential-drive vehicles, which is an adequate approximation with a static

center of gravity (CG) coincident with the wheelbase center. With a dual-arm mobile

manipulator, such as the Nuclear and Applied Robotics Group's VaultBot platform, the

center of gravity's location is dynamic and the differential-drive model is no longer valid.

This can result in large errors between desired and actual trajectories over even short

periods of time. In this work, the degree to which the platform's behavior changes with a

dynamic CG and the intuition behind these effects are discussed. Several different

approaches leading to the development of a heuristic model built to improve performance,

and the evaluation results of said model, are also discussed.

vi

Table of Contents

Chapter 1: Introduction ............................................................................................1

1.1. Application ...............................................................................................1

1.2. Robotic System ........................................................................................2

1.3. Navigation Fundamentals ........................................................................4

1.3.1. Differential Steering.....................................................................4

1.3.2. Skid-Steering................................................................................6

1.4. Software Configuration ............................................................................7

1.4.1. ROS ..............................................................................................7

1.4.2. Default Controller ........................................................................9

1.5. Dynamic Center-of-Gravity ...................................................................11

1.6. Error Visualization/Verification ............................................................11

1.6.1. Setup ..........................................................................................11

1.6.2. Preliminary Results ....................................................................14

1.7. Motivation & Report Organization ........................................................14

Chapter 2: Literature Review .................................................................................16

2.1. Robotics in the Nuclear Domain ............................................................16

2.2. Mobile Manipulators ..............................................................................18

2.3. Skid Steer ...............................................................................................20

Chapter 3: Analytical Solution...............................................................................21

3.1. Full Kinematics ......................................................................................22

3.2. Force Analysis .......................................................................................25

3.3. Closed Form Solution ............................................................................28

3.4. Numerical Solvers ..................................................................................28

3.5. Summary ................................................................................................29

Chapter 4: Empirical Solutions ..............................................................................30

4.1. Neural Network ......................................................................................30

4.1.1. Vicon Motion Tracking..............................................................30

4.1.2. Implementation ..........................................................................32

vii

4.1.3. Results ........................................................................................32

4.2. Heuristic Model .....................................................................................33

4.2.1. Experimental Setup ....................................................................33

4.2.1.1. Hector SLAM.................................................................34

4.2.1.2. Center-of-Gravity Solver ...............................................35

4.2.1.3. Center-of-Rotation .........................................................37

4.2.2. Model Setup ...............................................................................38

4.2.3. Results ........................................................................................39

4.3. Conclusions & Implementation .............................................................55

Chapter 5: Demonstration ......................................................................................58

5.1. Setup ......................................................................................................58

5.2. Results ....................................................................................................60

Chapter 6: Conclusions and Future Work ..............................................................69

6.1. Research Summary ................................................................................69

6.2. Future Work ...........................................................................................71

6.3. Concluding Remarks ..............................................................................72

Appendix A: MATLAB Numerical Solver............................................................73

Appendix B: Result Trajectories ............................................................................75

References ..............................................................................................................93

viii

List of Tables

Table 4-1: Average Rotational Velocity Ratio to Cmd. Velocity ..........................43

Table 4-2: Center-of-Rotation x-position for given Center-of-Gravity .................45

Table 4-3: Center-of-Rotation y-position for given Center-of-Gravity .................47

Table 4-4: Multivariate Regression of CoR y-position for given CG, part 1 ........49



Table 4-7: Equation Coefficients for Linear Regression of Figure 4-10 data .......51

Table 5-1: Qualitative Evaluation of Skid-Steer Controller in 42 configurations .64

Table 5-2: Quantitative Evaluation of Skid-Steer Controller in 42 configurations66

ix

List of Figures

Figure 1-1: L – Rescue Robot “Quince” [5], M – Lancaster U. Decommissioning

Robot [8], R – Wall Decontamination Robot MANOLA [9] .............2

Figure 1-2: UT NRG’s “VaultBot” Mobile Manipulator ........................................3

Figure 1-3: Clearpath Husky ....................................................................................6

Figure 1-4: VaultBot ROS node layout example .....................................................8

Figure 1-5: Open Loop Trajectories with Varying CG [14]: (A) Legend mapping arm

configuration to color code. (B) “S-curve” trajectory. (C) “Arc”

trajectory. (D) In-place rotation. .......................................................13

Figure 3-1: Kinematic Analysis of a Skid-Steer Mobile Manipulator ...................22

Figure 4-1: VaultBot with Vicon Retroreflective Markers ....................................31

Figure 4-2: In-Place Rotation Position Tracking, COM-y position @ 0.02 ..........40

Figure 4-3: In-Place Rotation Smoothed Angular Velocities, COM-y position @ -0.03

...........................................................................................................42

Figure 4-4: Average Rotational Velocity Error Ratios vs. CG position ................44

Figure 4-5: Average Rotational Velocity Error Ratios vs. CG x-position .............44

Figure 4-6: Center-of-Rotation x-position vs. Center-of-Gravity position ............46

Figure 4-7: Center-of-Rotation x-position vs. Center-of-Gravity x-position ........46

Figure 4-8: Center-of-Rotation y-coordinate vs. Center-of-Gravity location ........48

Figure 4-9: Center-of-Rotation y-coordinate vs. Center-of-Gravity x-coordinate 48

Figure 4-10: Center-of-Rotation y-position vs. Center-of-Gravity y-position ......49

Figure 4-11: Multivariate Regression of CoR y-position for given CG; Results ..50

Figure 4-12: Slopes of Linear Regressions from Figure 4-10 vs. CG x-position ..52

Figure 4-13: Intercepts of Linear Regressions from Figure 4-10 vs. CG x-position52

x

Figure 4-14: Predicted vs. Measured CoR y-position with Full Model .................53

Figure 4-15: Predicted vs. Measured CoR y-position with Symmetric Model......54

Figure 5-1: Centers of Gravity for Controller Tests ..............................................58

Figure 5-2: Controller Odometry in Scurve Front Left Configuration ..................60

Figure 5-3: Controller Odometry in Arc #2 Back Right Configuration ................61

Figure 5-4: Controller Odometry in Rotate Ready Configuration .........................62

Figure 5-5: Controller Odometry in Arc #4 Ready Back Configuration ...............63

Figure 5-6: Controller Odometry in Arc #1 Ready Back Configuration ...............67

Figure 5-7: Controller Odometry in Arc #2 Front Right Configuration ................68


configuration to color code. (B) “S-curve” trajectory. (C) “Arc”

trajectory. (D) In-place rotation. .......................................................70

Figure B-1: Controller Odometry in Arc #1 Back Left Configuration ..................75

Figure B-2: Controller Odometry in Arc #1 Back Right Configuration ................75

Figure B-3: Controller Odometry in Arc #1 Front Left Configuration .................75

Figure B-4: Controller Odometry in Arc #1 Front Right Configuration ...............76

Figure B-5: Controller Odometry in Arc #1 Ready Configuration ........................76

Figure B-6: Controller Odometry in Arc #1 Ready Back Configuration ..............76

Figure B-7: Controller Odometry in Arc #1 Stow Back Configuration ................77

Figure B-8: Controller Odometry in Arc #2 Back Left Configuration ..................77

Figure B-9: Controller Odometry in Arc #2 Back Right Configuration ................77

Figure B-10: Controller Odometry in Arc #2 Front Left Configuration ...............78

Figure B-11: Controller Odometry in Arc #2 Front Right Configuration .............78

Figure B-12: Controller Odometry in Arc #2 Ready Configuration......................78

Figure B-13: Controller Odometry in Arc #2 Ready Back Configuration ............79

xi

Figure B-14: Controller Odometry in Arc #2 Stow Back Configuration ..............79

Figure B-15: Controller Odometry in Arc #3 Back Left Configuration ................80

Figure B-16: Controller Odometry in Arc #3 Back Right Configuration ..............80






Figure B-22: Controller Odometry in Arc #4 Back Left Configuration ................83

Figure B-23: Controller Odometry in Arc #4 Back Right Configuration ..............84






Figure B-29: Controller Odometry in Rotate Back Left Configuration ................86

Figure B-30: Controller Odometry in Rotate Back Right Configuration ..............86

Figure B-31: Controller Odometry in Rotate Front Left Configuration ................87

Figure B-32: Controller Odometry in Rotate Front Right Configuration ..............87

Figure B-33: Controller Odometry in Rotate Ready Configuration ......................88

Figure B-34: Controller Odometry in Rotate Ready Back Configuration .............88

Figure B-35: Controller Odometry in Rotate Stow Back Configuration ...............89

Figure B-36: Controller Odometry in S-curve Back Left Configuration ..............89

Figure B-37: Controller Odometry in S-curve Back Right Configuration ............90

Figure B-38: Controller Odometry in S-curve Front Left Configuration ..............90

xii

Figure B-39: Controller Odometry in S-curve Front Right Configuration ............91

Figure B-40: Controller Odometry in S-curve Ready Configuration ....................91

Figure B-41: Controller Odometry in S-curve Ready Back Configuration ...........92

Figure B-42: Controller Odometry in S-curve Stow Back Configuration .............92

1

Chapter 1: Introduction

1.1. APPLICATION

While the capabilities of artificial intelligence agents as portrayed in pop culture

and science fiction have long exceeded reality, the field of robotics may finally be catching

up to expectations. Previously dominated by specialized single task machines, such as

industrial workstations or dedicated vacuum cleaners, and carefully optimized laboratory

experiments and demonstrations, the field is now quickly growing to include increasingly

innovative and diverse applications in real-world scenarios. From headline-grabbing

efforts in self-driving passenger vehicles by major corporations such as Google and Tesla,

to lower profile yet still important advances in medical robotics, autonomous machines are

seeing increased development and usage across many different fields and disciplines.

One such area in which robots have seen increased demand for deployment is in

hazardous environments, particularly those found in the nuclear industry. The development

of autonomous devices to assist or even replace human workers in environments that would

be dangerous to those workers is a worthwhile endeavor. For example, recent events such

as the Fukushima Daiichi accident in 2011 [1] and the Waste Isolation Pilot Plant incident

in 2014 [2] have demonstrated the need for remote agents to enter and perform critical

tasks in high radioactivity zones, and many of these agents have been designed and

deployed, with varying levels of success [3][4]. Regardless of their design or primary tasks,

it is highly desirable that these agents be robust enough to successfully navigate uncertain,

cluttered, and sometimes dangerous terrain such that they can return safely upon

completion of the task. Some agents may also be required to complete high-effort tasks

such as opening doors or moving debris, whether as their primary mission or as a necessary

subtask to reach their primary mission. These agents must then be able to support and/or

2

manipulate significant payloads, and have sufficiently large operational workspaces for

successful manipulation.

1.2. ROBOTIC SYSTEM

Numerous mobile platforms and mobile manipulators have been developed for

nuclear and other hazardous environments [5][6][7]. These systems in recent years have

developed capabilities to move beyond simple teleoperation and execute tasks more

autonomously [8][9].

Figure 1-1: L – Rescue Robot “Quince” [5], M – Lancaster U. Decommissioning Robot

[8], R – Wall Decontamination Robot MANOLA [9]

One such system is the VaultBot, a mobile manipulator research platform in the

Nuclear and Applied Robotics Group at the University of Texas at Austin. The VaultBot

primarily consists of a 4-wheeled skid-steer Clearpath Husky mobile base platform with

two 6-DOF Universal Robotics “UR5” manipulators mounted above on a custom bulkhead.

3

Figure 1-2: UT NRG’s “VaultBot” Mobile Manipulator

The Husky base provides a wide, stable footprint which is sturdy enough to support

both arms, their controllers, and their payloads without any tipping, oscillation, or other

forms of movement in the base. Also, the 4 driven wheels provide additional traction and

redundant points of contact which help in navigation over loose soil and/or debris and

minimize chances of the robot getting stuck. These wheels are driven using a differential

steering system to minimize mechanical complexity and maximize durability and load

capability. However, unlike traditional differentially steered vehicles, the Husky’s

redundant, fixed wheels classify it as a “skid-steer” vehicle.

Much like tracked systems such as tanks or some construction equipment, wheeled

skid-steer vehicles rely on differing left and right side wheel velocity directions for

rotation. But unlike tracked systems, the smaller contact surface area for wheeled vehicles

4

typically produces less wear on themselves and the environment. These rotations depend

on lateral slip from the wheels, which introduces complex wheel-to-ground dynamic

interactions that are difficult to model. These then produce a mathematically complex,

nonlinear behavior for the vehicle as a whole, often depending on factors outside of the

vehicle itself such as terrain composition or slope. Due to these external factors, an exact

kinematic mapping of wheel input speeds to vehicle output motion cannot be precisely

determined. However, approximations can be made that approach the true behavior [10].

Because the control interfaces are at first quite similar (two motors, each controlling one

side of the robot), the differences between differentially steered and skid-steered vehicles

can at times be overlooked or over-simplified (see Clearpath’s controller implementation

in Section 1.4). In reality, however, the differences are significant and thus a major focus

of this work.

1.3. NAVIGATION FUNDAMENTALS

1.3.1. Differential Steering

An effective and commonly used design in mobile robotics, differential

steering consists of two independently driven, parallel wheels on the same fixed axis, with

another one or more passive wheels to stabilize the base. The design is effective because it

allows for a reasonable degree of maneuverability with almost zero slip; the robot can

rotate in place, travel forwards or backwards, or combine the two maneuvers for an arc-

like trajectory while the wheels maintain nearly pure rolling motion. The resulting

kinematic equations of motion for the vehicle translational and rotational velocities are:

5

𝑣𝑥 = 𝑟 (𝜔𝑙 + 𝜔𝑟

2 ) (1.1)

𝑣𝑦 = 0 (1.2)

�̇� = 𝑟 (𝜔𝑙 − 𝜔𝑟

𝐿) (1.3)

where ωl and ωr are the rotational velocities of the left and right wheels, r is the radius of

the wheels, and L is the distance between the wheels along the common axle, or the wheel

base. Note that vy is always 0; this reflects that at no instant in time may the vehicle move

directly sideways. However, differentially steered robots are frequently designed to be

close to if not fully rotationally symmetric, so that in-place turns are simple and of little

consequence from a collision perspective. Therefore, a differentially steered robot that

needs to make a lateral translation can deconstruct the move into three motions: a rotation

towards the goal, forwards motion to the goal location, and a final rotation to the desired

orientation. On smooth, planar, controlled surfaces, the differential steering design is

efficient, simple, and effective. On rougher terrain, however, having only 2 driven wheels

can quickly become a liability, leading to less stability, less traction, and a higher potential

for getting stuck.

6

1.3.2. Skid-Steering

Figure 1-3: Clearpath Husky

Skid-steer differential systems such as the Clearpath Husky (Figure 1-3) are similar

to standard differential systems in that they take 2 inputs, left and right wheel speed.

However, with 4 driven wheels and thus 4 points of contact, there is much more stability

for rough terrain. The Husky’s two left wheels are connected by a single drivetrain, and

likewise for the right side. At a glance, the kinematics are exactly the same: the husky may

move directly forwards or backwards by rotating the left and right wheels in the same

direction at the same speed, turn in place by rotating them in opposite directions at the same

speed, or any combination of the rotational and translational motions by varying the speeds

and directions. In reality, however, Equations 1.1-1.3 if implemented directly would

significantly overestimate the actual motion. Due to the redundant points of contact, there

is significant slip in any turning motion performed by the Husky, hence the term “skid-

steer”. Rotation of the vehicle about any point in space will cause at least two of the wheels

to have translation with components orthogonal to their plane of rotation. Preliminary

analysis has demonstrated that for any given in-place rotation, the resulting change in

7

orientation will be less than 50% of that which is predicted by the standard no-slip,

differential steering model.

1.4. SOFTWARE CONFIGURATION

1.4.1. ROS

The primary control structure of the system depends on ROS [11], an open-source

development framework that is becoming one of the ubiquitous software tools in robotics.

As it pertains to the VaultBot, a simple overview of ROS is as follows: A collection of

“nodes” act as drivers, to control and communicate with the various actuators, sensors, and

other hardware devices, or as processors, to react to and control the drivers as necessary.

These nodes primarily communicate by “publishing” data to “topics” that other nodes can

“subscribe” to for receiving data, or vice versa. As many as 21 of these nodes automatically

run on startup of the VaultBot, controlling and interfacing with systems such as the onboard

IMU, a joystick controller for teleoperation, and the SICK LIDAR LMS511 rangefinder,

and performing tasks such as diagnostic management and data filtration.

8

Figure 1-4: VaultBot ROS node layout example

One of the most beneficial aspects of ROS is the modular nature of its node/topics

structure when combined with its open source mission. This means that if a researcher or

industry partner introduces a new piece of hardware, or a new way of interacting with or

utilizing existing hardware, the software that they write can be easily bundled into a ROS

node or series of nodes called a “package”. This package can then be utilized by anyone in

the ROS community who has need of it. Even high level decision-making or artificial

intelligence architectures can be, and are, shared as ROS packages for the greater

community to utilize.

Multiple ROS packages can also be further bundled into stacks, such as the

“Navigation Stack” [12]. This stack contains all high-level packages necessary for the

intelligent navigation of a traditional differential-drive or holonomic wheel robot. This

includes management of a 2D map environment and associated costmaps, the amcl [13]

localization algorithm, global and local path planners for trajectory optimization and

collision avoidance, and recovery procedures for lost or stuck robots. The navigation stack

9

is utilized on the Husky platform, but as the VaultBot is not holonomic or truly differential-

drive there are significant performance issues. The localization package amcl, in

particular, diverges from the truth rapidly and is insufficient for safe autonomous operation

in its current state. One approach to solve this issue would be to rework amcl, or to attempt

to create or implement an entirely different localization algorithm, but this work chooses

to address the underlying faulty kinematic assumptions which cause the issue in the first

place.

1.4.2. Default Controller

For the Clearpath Husky mobile platform, the drivers which communicate with the

motors are in husky_node, which continuously subscribes to an assortment of topics.

One of these topics is cmd_vel, which accepts a translational velocity and a rotational

velocity vector. When data is published to the cmd_vel topic, husky_node pulls that

data, extracts the x velocity 𝑣𝑥 and z angular velocity θ, and feeds these into

diff_drive_controller to calculate the necessary right and left wheel velocities.

While not a node of its own, it is a generic controller used for differentially steered devices,

and handles both body velocity to wheel speed conversions and dead-reckoning odometry

calculations, using the following equations:

�̇�𝑙 =1

𝑤𝑟𝑟(�̇� −

𝑑𝑚𝑤𝑠�̇�

2) (1.4)

�̇�𝑟 =

1

𝑤𝑟𝑟(�̇� +

𝑑𝑚𝑤𝑠�̇�

2) (1.5)

�̇� =

𝑤𝑟𝑟(�̇�𝑙 + �̇�𝑟)

2 (1.6)

�̇� = 0 (1.7)

�̇� =

1

𝑑𝑚𝑤𝑠

[𝑤𝑟𝑟(�̇�𝑟 − �̇�𝑙)] (1.8)

10

where 𝑤𝑟 is the “wheel_radius_multiplier”; r is the wheel radius; 𝑤𝑠 is the

“wheel_separation_multiplier”; �̇�, �̇�, and �̇� are the vehicle linear and angular

velocities; 𝑑𝑚 is the wheel base of the vehicle; and �̇�𝑙 and �̇�𝑟 are the left and right wheel

speeds. With the exception of the multiplier terms, these are the same basic differential

steering equations as Equations 1.1-1.3. The multipliers are typically set to 1.0 and are used

as slight tuning parameters, but in the case of the VaultBot are slightly different. Due to

the unique power requirements of carrying two industrial manipulators, their controllers,

and their payloads, the Husky base was outfitted with a unique gear train. This resulted in

a modification of the motor to wheel relationship, and is most easily accounted for in 𝑤𝑟.

Clearpath recommended setting this parameter to a general value of 0.5, but

experimentation (comparison of raw encoder output to observation of a set number of

wheel rotations) revealed a more accurate value of 0.527. This is a constant parameter, so

future references to control equations will assume this value to be folded into 𝑟 itself for

simplicity. The second multiplier, 𝑤𝑠, is the primary heuristic used to approximately

account for the slip inherent to the Husky’s skid steer configuration. Set to a value of 1.875,

the value appears to be a fair correction under default operating conditions. However, as

will be discussed in future sections, the dynamic nature of the robot’s manipulators results

in operating conditions that are often far from the default.

Once the desired wheel speeds have been calculated, husky_node then uses a

speed control feedback loop, in conjunction with wheel encoders, to set and maintain the

wheels at those speeds until a new value is given.

11

1.5. DYNAMIC CENTER-OF-GRAVITY

In addition to the standard challenges offered by a skid-steer vehicle, observations

of in-place rotations during testing operations have indicated that the VaultBot tends to

rotate about its center-of-gravity (CG). This is significant because the VaultBot has the

challenging additional characteristic of a highly variable CG due to its manipulators and

potentially varying (and substantial) payloads. Therefore, at any given time the mobile base

could behave differently depending on the positions of the mobile manipulators and/or their

payloads.

As mentioned previously, the default controller for the Husky platform is a

differential-steer controller with a heuristic constant multiplier to account for the slip.

While this is a roughly valid approximation for the base’s behavior in the VaultBot’s

default configuration (with the arms stowed close to the base), it is far from ideal and

diverges from the truth rapidly when in non-default configurations.

1.6. ERROR VISUALIZATION/VERIFICATION

In order to evaluate the existence and severity of potential errors introduced by an

odometry model which does not account for a dynamic CG, an experiment was setup to

compare various open-loop maneuvers with changing arm configurations.

1.6.1. Setup

In order to test the effects of a changing CG, the VaultBot was given open-loop

commands for three separate behaviors while in three different arm configurations,

resulting in 9 trajectories. A camera was positioned on a tripod on a balcony overlooking

the test area, and video was taken of each experiment. Note that for each group of

12

configurations for a given behavior, the robot’s base started at the same position and

orientation.

For these preliminary experiments, all arm positions were longitudinally

symmetric. Therefore, the CG was assumed to be located on the x-axis for all tests. As

shown in Figure 1-5a, the first arm configuration was the standard “back stow” position,

with the arms tucked closely into the body and the elbows towards the rear of the vehicle.

Due to the mounting configuration of the arms, this results in the CG being closest to the

center of the wheel base of the 3 configurations. The second configuration was “front

stow”, again with the arms tucked closely to the body but with the elbows in front of the

vehicle, thus moving the CG forwards. The third configuration was “ready”, with the arms

deployed forwards as if ready to manipulate an object in front of the vehicle, moving the

CG even farther along the x-axis.

The first open loop behavior was the “Arc” behavior, with constant forward and

rotational velocities:

𝑣𝑥 = 0.5 𝑚/𝑠

�̇� = −0.2 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 6.0𝑠 (1.9)

The second behavior was the “S-curve” trajectory, with a constant forward velocity

and a sinusoidal rotational velocity:

𝑣𝑥 = 0.8 𝑚/𝑠

�̇� = −0.6 ∗ sin (2𝜋𝑡

9.0) 𝑟𝑎𝑑/𝑠

} 𝑓𝑜𝑟 0 < 𝑡 < 9.0𝑠 (1.10)

The final behavior was a simple in-place rotation:

13

𝑣𝑥 = 0 𝑚/𝑠

�̇� = −0.5 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 3.0𝑠 (1.11)

Finally, in order to verify the repeatability of the tests, the “back stow”

configuration and “S-curve” trajectory combination was repeated 3 times. Under these

controlled conditions with the same arm configurations and open loop commands, the

difference in final positions was negligible.


configuration to color code. (B) “S-curve” trajectory. (C) “Arc” trajectory.

(D) In-place rotation.

14

1.6.2. Preliminary Results

Once the tests were completed, the starting and ending position shots for each test

were extracted from the video. They were then digitally overlaid on top of each other, for

comparison in Figure 1-5b - Figure 1-5d. For clearest comparison, the 3 arm configurations

were given a color code, and then a rectangular portion of the VaultBot’s mounting bracket

was traced in each configuration’s respective color. The starting position was represented

by a white rectangle. For the “Arc” and “S-curve” behaviors, rough approximations of the

trajectory were sketched as well. As can be seen from the photos, a clear difference can be

seen when the center-of-gravity changes. Over a relatively short distance in the “S-curve”

behavior, the VaultBot in the “ready” configuration ends up at a significantly different

location from when in the “back stow” arrangement. In all 3 behaviors, the CG’s distance

forwards along the x-axis appears to correspond to more rotation for a given command;

this is particularly evident with the in-place rotation behavior.

The primary purpose of these experiments was to experimentally validate the

hypothesis that the error was significant. In the three configurations, the CG was estimated

to move by up to 0.25 meters which was determined from video analysis of the in-place

rotation behaviors, which also showed a rotation difference of as much as 55 degrees. And

in the translational trajectories, the difference in the target locations was estimated to be up

to 0.85 meters. This verifies that the error is significant, and validates the efforts to address

it.

1.7. MOTIVATION & REPORT ORGANIZATION

For open-loop navigation procedures such as teleoperation, the benefits of

improving the kinematic model are readily apparent; a robot which behaves as expected

15

improves user experience and performance. Autonomous behavior, however, typically

relies on closed loop navigation processes which, if utilizing sufficiently powerful sensors

and computational power, can often “wash over” modeling errors. Nevertheless, the

probabilistic closed loop models widely used in robotics today still utilize an open-loop

model of the system for the “prediction” step, and a significantly inaccurate model adds

unnecessary computational effort to the system and increases the likelihood of divergent

behavior. Therefore, efforts to improve the underlying kinematic model should bear fruit

in multiple capacities.

The objectives of this work are as follows: Commonly available motion planners

and previous skid-steer kinematic modeling efforts will be reviewed in Chapter Two to see

if they address the issue of a variable CG, and then their effectiveness will be evaluated.

Then a review of various attempts made at deriving an analytic solution to a more accurate

kinematic model will be covered in Chapter Three. Next, a discussion of attempted empiric

solutions, including the final heuristic solution and lessons learned from its derivation, will

be presented in Chapter Four. Chapter Five will contain a comparison of the solution

against the default controller and an evaluation of the success of the model. Finally,

concluding thoughts and a discussion of future work will comprise Chapter Six.

16

Chapter 2: Literature Review

2.1. ROBOTICS IN THE NUCLEAR DOMAIN

The need for robotic solutions in the nuclear domain is not a recently realized

concept. Raymond C. Goertz was one of the earliest adopters, utilizing telerobotics at

Argonne National Laboratory in 1949 to handle radioactive material [15]. In 1985, Moore

[16] published an extensive review of robotics in the nuclear power industry, discussing

robots by companies such as Westinghouse involved in inspection and maintenance

processes, as well as DOE-supplied robots to assist with cleanup of the Three Mile Island

incident. Briones et al. [17] in 1994 introduced prototypes for a wall-climbing robot

designed for inspection in boiling water reactor (BWR) plants, using suction cups and

flexible components to navigate up and across vertical surfaces. Ishikawa and Suzuki [18]

proposed a collaborative, semi-autonomous approach to controlling a rudimentary mobile

robot for use in nuclear power plants in 1997. Finally, Iwano et al. [19] in 2004 presented

a conceptual design of swarm rescue robots, to safely recover injured or incapacitated

humans from the scene of a nuclear plant accident such as the criticality accident at Japan’s

Tokai Factory of Nuclear Fuel Conversion Plant in 1999. Nevertheless, the pace at which

these technologies were developed and introduced pales in comparison to the innovations

spurred by recent events.

Modern nuclear incidents, such as the crisis at the Fukushima Daiichi Nuclear

Power Station in March 2011 and the spill at the Waste Isolation Pilot Plant in New Mexico

in February 2014, spurred many robotic companies and researchers around the world into

action. For example, Nagatani et al. [5] represented a collaborative effort amongst

researchers from 3 Japanese universities to retrofit a mobile rescue robot named Quince

for survey, exploration, and measurement missions in the damaged nuclear complex. Later,

17

Nagatani et al. published an update [1] on their successes and failures, and discussed plans

for continued operation with improved iterations of the Quince robot. Other efforts arose

not in direct response to the events at Fukushima, but as a result of the political

repercussions. Notheis et al. [9] presented designs for a decommissioning robot system

named MANOLA in response to Germany’s mandate to shut down all nuclear power plants

by 2022, which in turn was in direct response to the Fukushima incident. A complex design,

MANOLA is a wall-climbing robot equipped with tools for laser ablation of surfaces, and

with an accompanying mobile transport system to deliver MANOLA to the correct walls.

Other decommissioning efforts include work by Besset and Taylor [8] of Lancaster

University in the UK; RICA, a mobile sampling robot by Ducros et al. [20] of the CEA

(French Atomic Energy Commission); and AVEXIS, a series of underwater robotic

vehicles by Griffiths et al. [4] for use in storage ponds as part of the decommissioning of

the Sellafield nuclear facilities in Cumbria, U.K.

One of the more exotic applications is presented by Jiang et al. [21] in response to

the WIPP spill. In order to inspect and swab the surface of the exhaust shaft, which was

subject to radioactive smoke due to the incident, Jiang et al. propose a semi-autonomous

flying drone: the Dextrous Hexrotor. In the paper they discuss initial designs, solution

prototypes, and testing inside a grain solo.

Even without the motivation of a specific event, development for robotics

applications in hazardous environments continues. Huang et al. [7] propose a mobile

robotic solution for CBRN sampling; that is, flexible for applications in Chemical,

Biological, Radiological, and Nuclear incident response. RIANA is a mobile robot solution

presented by Kanaan et al. [22] of the French nuclear energy company AREVA, “dedicated

18

for investigations and assessments of nuclear Areas”, while Li et al. [6] propose a mobile

robot for “environment monitoring”.

While many significant efforts have clearly been made in nuclear robotics, a

majority of these efforts have been single-track; that is, they were specially engineered and

utilized for specific tasks and end-users. While this specialization is a valid approach in

some aspects, it limits the potential for shared knowledge and increases the occurrence of

separate research teams repeating the same mistakes. A university focused research effort,

such as the Nuclear and Applied Robotics Group at UT Austin, allows for broader efforts

utilizing open-source software and the academic community to design systems accessible

to multiple applications and user bases.

2.2. MOBILE MANIPULATORS

While plenty of robotic solutions consist solely of one or several fixed

manipulators, or of a mobile sensing robot with cameras and other sensors but no additional

actuators, much greater mission flexibility can be achieved with the marriage of these two

concepts: a mobile manipulator. While it can also be equipped with sensing and

environment monitoring devices, the primary design intent of a mobile manipulator is

typically to interact with the environment in some way, whether it be retrieving material,

opening doors, or even rescuing people in harm’s way. Some previously discussed efforts

which fit into the mobile manipulator classification include: Quince by Nagatani et al. [1],

[5]; the unnamed robotic solutions proposed by Besset and Taylor [8] and Huang et al. [7],

RIANA by Kanaan et al. [22], and RICA by Ducros et al. [20]. Unfortunately, there is little

discussion within these papers on the navigation or operation of the mobile base. Also,

with the exception of RIANA, all of these solutions have tracked wheel systems. RIANA

19

on the other hand is a 4-wheeled skid steer system with a 3 DOF manipulator arm, and is

perhaps the closest modern solution in the nuclear domain to the VaultBot. Navigation is

only briefly discussed, however, and “the precision of the navigation… depends on the

environment and the used sensors”, indicating complete reliance on closed-loop sensing.

Outside of the nuclear domain, mobile manipulators take on a much broader

spectrum of designs and approaches. Trulls et al. [23] discuss the navigation aspects of

Segway-based service robots in urban scenarios, while Stentz et al. [24] introduce CHIMP,

a highly complex, humanoid system developed by Carnegie Mellon University for the

DARPA Robotics Challenge. CHIMP is designed to drive on two tracked legs, or lower

onto its arms as well for 4-tracked mobility. Even non-wheeled solutions are being

developed, such as RoboSimian by Hebert et al. [25], “a statically stable quadrupedal

robot” which uses multi-jointed limbs as traversal implements as well as manipulation

tools. Ben-Tzvi [26] of George Washington University presents a small, geometrically

symmetrical tracked platform with a closely integrated 2-DOF arm that assists in mobility

when not performing manipulation tasks, which is claimed to result in a much higher

payload capacity than is typical for mobile manipulators.

While most of these works concern themselves with the design and implementation

of their novel robot concept as a whole, some works take a more theoretical approach and

more closely analyze the relationship between a robot’s mobility given the presence of a

manipulator, or conversely manipulation capabilities and procedures given the additional

platform mobility. Addressing the former, He [27] proposes a “tip-over avoidance

algorithm” for mobile manipulators, moving the manipulator as necessary to manage

multiple dynamic scenarios such as non-level surfaces and high turning speeds. Ide et al.

20

[28] present an example of the latter, using model predictive control to unify control and

trajectory planning of a manipulator and a differentially steered mobile base.

The most relevant work to this thesis is likely that presented by Liu and Liu [29] of

Ryerson University in Toronto. In their work, Liu and Liu create a thorough kinetic and

kinematic model of a proposed mobile manipulator with a tracked base and a single

manipulator arm. Importantly, this model makes the simplifying assumption that the

tracked system behaves as a six-wheeled skid-steer base, and the kinetic model takes into

account the forces induced by the manipulator position and motion, as well as any external

forces on the end-effector (such as payloads). However, their model is solved and utilized

in simulation, rather than real time. A closer analysis of their approach and lessons learned

are discussed in Chapter 3.

2.3. SKID STEER

The specific configuration of the VaultBot’s mobile base, wheeled skid-steer, has

also been the subject of plentiful research. Several groups have investigated better closed-

loop control of skid-steer vehicles, such as Caracciolo et al.[30], the extending work of

Kowzlowski et al. [31], and Pentzer et al. [32] of Pennsylvania State University. These

implementations, while thorough and effective, all depend on a measurement input of the

robot’s state independent of odometry during operation, typically GPS. Mandow et al. [33]

discuss methods for experimental development of a better kinematic model, which is then

utilized real-time for improved performance. However, although they discuss the potential

effects of different center-of-gravity locations, it is not implemented into the model and the

CG is assumed to be constant.

21

Chapter 3: Analytical Solution

Based on dynamic models found in the literature and related efforts to solve this or

similar problems, several approaches were attempted in finding a solution to the presented

problem. These included:

A closed form analytical model

A numerical solution to the analytical model

Neural network training

A heuristic model

This chapter discusses approaches using the comprehensive full kinematic and

dynamic models in order to find an analytical solution. If possible, it would then be possible

to much more accurately control and track the motion of the robot as desired based on

wheel speeds and arm configurations. This approach proved untenable due to significant

complexities introduced by the nonlinearities defining the tire/ground interactions.

However, the approach is documented here to assist with any future efforts that consider

this approach. Furthermore, it may be possible to simplify or validate the presented models

in future efforts by utilizing the following empirical results. For the eventual solution

employed in this paper, see Section 5.2.

22

3.1. FULL KINEMATICS

Figure 3-1: Kinematic Analysis of a Skid-Steer Mobile Manipulator

Based on the work of Liu and Liu [29], an attempt was made to model and solve

the full kinematic model of the mobile manipulator, including the nonlinear slip

interactions at the four wheels. Though Liu and Liu worked with a tracked vehicle, their

treatment of the vehicle as a six-wheeled skid-steer platform allows for a natural extension

to the VaultBot’s four-wheeled setup. Also, the presence of an additional manipulator arm

on the VaultBot should only add tedium to the calculations, but not additional complexity,

particularly if the two are represented by a single composite center-of-gravity. The primary

23

coordinate frames are as follows: 𝑂𝑚 − 𝑋𝑚𝑌𝑚𝑍𝑚 is a fixed local frame, where the

coordinate plane 𝑋𝑚𝑂𝑚𝑌𝑚 is parallel to the ground and passes through all wheel axes, so

it has a positive z offset equal to the wheel radius. 𝑂𝑚𝑋𝑚 points directly forwards to the

front of the vehicle, and therefore the positive direction of 𝑂𝑚𝑌𝑚 is to the left. The location

of the vehicle’s CG is represented as the dynamic coordinate frame 𝑂𝐺 − 𝑋𝐺𝑌𝐺𝑍𝐺 , which

maintains the same orientation as frame 𝑂𝑚 − 𝑋𝑚𝑌𝑚𝑍𝑚 but is subject to dynamic

translations, represented by 𝑥𝐺𝑚, 𝑦𝐺

𝑚, 𝑧𝐺𝑚, and their time derivatives. Liu and Liu also present

an inertial base frame 𝑂𝐵 − 𝑋𝐵𝑌𝐵𝑍𝐵, resulting in the following dynamic equations:

�̇�𝑚 =

[𝑟(�̇�𝑙 + �̇�𝑟) + (�̇�𝑙𝑥 + �̇�𝑟𝑥)]𝑐𝑜𝑠𝜙𝑚

2

+𝑑0[𝑟(�̇�𝑟 − �̇�𝑙) + (�̇�𝑟𝑥 − �̇�𝑙𝑥)]𝑠𝑖𝑛𝜙𝑚

𝑑𝑚

(3.1)

�̇�𝑚 =

[𝑟(�̇�𝑙 + �̇�𝑟) + (�̇�𝑙𝑥 + �̇�𝑟𝑥)]𝑠𝑖𝑛𝜙𝑚

2

−𝑑0[𝑟(�̇�𝑟 − �̇�𝑙) + (�̇�𝑟𝑥 − �̇�𝑙𝑥)]𝑐𝑜𝑠𝜙𝑚

𝑑𝑚

(3.2)

�̇�𝑚 =

1

𝑑𝑚

[𝑟(�̇�𝑟 − �̇�𝑙) + (�̇�𝑟𝑥 − �̇�𝑙𝑥)] (3.3)

where �̇�𝑚, �̇�𝑚, 𝜙𝑚 represent the linear velocities and heading of the mobile platform

relative to the base frame, 𝑟 is the wheel radius, �̇�𝑙 , �̇�𝑟 are the left and right wheel speeds,

�̇�𝑙𝑥, �̇�𝑟𝑥 are the longitudinal slip values of the left and right wheel sets, 𝑑𝑚 is the width of

the vehicle track, and 𝑑0 is the offset along 𝑂𝑚𝑋𝑚 of the instantaneous Center-of-Rotation

(CoR). However, as this effort is only concerned with the local movement and velocities

of the VaultBot, frames 𝑂𝑚 − 𝑋𝑚𝑌𝑚𝑍𝑚 and 𝑂𝐵 − 𝑋𝐵𝑌𝐵𝑍𝐵 are assumed to be always

coincident at any given time, with the exception of the z offset which is a constant.

Therefore:

24

𝑥𝑚 = 𝑦𝑚 = 𝜙𝑚 = 0, 𝑧𝑚 = 𝑟

which allows the ‘m’ subscript to be dropped and results in the simplified equations:

�̇� =[𝑟(�̇�𝑙 + �̇�𝑟) + (�̇�𝑙𝑥 + �̇�𝑟𝑥)]

2 (3.4)

�̇� = −𝑑0[𝑟(�̇�𝑟 − �̇�𝑙) + (�̇�𝑟𝑥 − �̇�𝑙𝑥)]

𝑑𝑚= −𝑑0�̇� (3.5)

�̇� =1

𝑑𝑚

[𝑟(�̇�𝑟 − �̇�𝑙) + (�̇�𝑟𝑥 − �̇�𝑙𝑥)] (3.6)

Note that if the CoR has no longitudinal offset and there is no longitudinal slip, in

other words if 𝑑0 = 0 𝑎𝑛𝑑 �̇�𝑟𝑥 = �̇�𝑙𝑥 = 0, then the equations simplify to:

�̇� =𝑟(�̇�𝑙 + �̇�𝑟)

2 (3.7)

�̇� = 0 (3.8)

�̇� =1

𝑑𝑚

[𝑟(�̇�𝑟 − �̇�𝑙)] (3.9)

which is the traditional set of equations for differentially steered vehicles. The longitudinal

slips for the left and right wheels, respectively, can be defined as follows:

�̇�𝑙𝑥 = �̇� −𝑑𝑚�̇�

2− 𝑟�̇�𝑙 (3.10)

�̇�𝑟𝑥 = �̇� +𝑑𝑚�̇�

2− 𝑟�̇�𝑟 (3.11)

Equally as important are the lateral slips, shared by the front and rear wheel sets:

25

�̇�𝑓𝑦 = �̇� + 𝑙𝑓�̇� (3.12)

�̇�𝑏𝑦 = �̇� + 𝑙𝑏�̇� (3.13)

𝑙𝑓 = −𝑙𝑏 =𝑊𝑏

2 (3.14)

where 𝑊𝑏 is the VaultBot wheel base. These slips occur at the four wheel contact points:

𝑃𝑓𝑙, 𝑃𝑓𝑟 , 𝑃𝑏𝑙, 𝑃𝑏𝑟 where the subscripts ‘fl’, ‘fr’, ‘bl’, and ‘br’ correspond to ‘front left’, ‘front

right’, ‘back left’, and ‘back right’ respectively.

3.2. FORCE ANALYSIS

The friction and resistance forces at the wheels then are modeled the same as in the

work of Liu and Liu:

𝐹⋆◊

𝑥 = −𝜇𝑥𝑁⋆◊ [1 − exp (−𝐾|�̇�◊𝑥|

max(|�̇�◊𝑥 + 𝑟�̇�◊|, |𝑟�̇�◊|))]

�̇�◊𝑥

√�̇�◊𝑥2 + �̇�⋆𝑦

2

(3.15)

𝐹⋆◊

𝑦= −𝜇𝑦𝑁⋆◊[1 − exp(−𝐾)]

�̇�⋆𝑦

√�̇�◊𝑥2 + �̇�⋆𝑦

2

(3.16)

𝑅⋆◊ = 𝑓𝑟𝑁⋆◊ (3.17)

where ‘⋆’ represents ‘f’ or ‘b’; ‘◊’ represents ‘l’ or ‘r’; 𝜇𝑥, 𝜇𝑦 are the friction coefficients

between the tire material and the ground, 𝐾 is a constant “determined by pull slip test”, 𝑁

represents the normal force at the contact point, and 𝑓𝑟 is the coefficient of motion

resistance, also experimentally determined. The inertial accelerations of the CG are also

the same, with the addition of the 𝜙𝑚 = 0 simplification:

�̈�𝐺𝐵 = �̈�𝑚

𝐵 + �̈�𝐺𝑚 − 𝑦𝐺

𝑚�̈� − 2�̇�𝐺𝑚�̇� − 𝑥𝐺

𝑚�̇�2 (3.18)

�̈�𝐺𝐵 = �̈�𝑚

𝐵 + �̈�𝐺𝑚 + 𝑥𝐺

𝑚�̈� + 2�̇�𝐺𝑚�̇� − 𝑦𝐺

𝑚�̇�2 (3.19)

26

�̈�𝐺𝐵 = �̈�𝐺

𝑚 (3.20)

Liu and Liu include additional “centrifugal acceleration” terms; however, these

terms are accounted for in the inertial acceleration composites. Therefore, the inclusion of

these additional terms is believed to be an error of redundancy and was thus omitted for

this work. It was verified, however, that the inclusion or exclusion of these terms has no

effect on the conclusion reached by this approach, which is discussed in Section 3.3. The

equations detailed thus far now allow the derivation of a system of six dynamic equations

describing the forces involved in the motion of the VaultBot. The first equation comes from

a sum of forces along the 𝑂𝑚𝑍𝑚 axis:

∑ ∑ 𝑁⋆◊

◊=𝑙,𝑟⋆=𝑓,𝑏

= 𝑚(𝑔 + �̈�𝐺𝐵) − 𝐹𝑒𝑥𝑡

𝑍 (3.21)

Next is the summation of moments about the line connecting contact points 𝑃𝑓𝑙 and

𝑃𝑏𝑙:

𝑑𝑚 ∑ 𝑁⋆𝑟

⋆=𝑓,𝑏

= 𝑚(𝑔 + �̈�𝐺𝐵) (

𝑑𝑚

2− 𝑦𝐺

𝑚)

−𝑝𝑒𝑧𝐹𝑒𝑥𝑡𝑦

− 𝐹𝑒𝑥𝑡𝑍 (

𝑑𝑚

2− 𝑝𝑒𝑦) + 𝑚𝑧𝐺

𝐵�̈�𝐺𝐵

(3.22)

Similarly follows the summation of moments about the line connecting contact

points 𝑃𝑓𝑙 and 𝑃𝑓𝑟:

𝑊𝑏(𝑁𝑏𝑟 + 𝑁𝑏𝑙) = 𝑚 (

𝑊𝑏

2− 𝑥𝐺

𝑚) (𝑔 + �̈�𝐺𝐵)

+𝑚𝑧𝐺𝐵�̈�𝐺

𝐵 − 𝑝𝑒𝑧𝐹𝑒𝑥𝑡𝑥 − 𝐹𝑒𝑥𝑡

𝑍 (𝑊𝑏

2− 𝑝𝑒𝑥)

(3.23)

27

Next is the summation of forces along the 𝑂𝑚𝑋𝑚 axis:

∑ ∑ 𝐹⋆◊

𝑥


= 𝑚�̈�𝐺𝐵 + ∑ ∑ 𝑅⋆◊


− 𝐹𝑒𝑥𝑡𝑥

= 𝑚�̈�𝐺𝐵 + 𝑓𝑟[𝑚(𝑔 + �̈�𝐺

𝐵) − 𝐹𝑒𝑥𝑡𝑍 ] − 𝐹𝑒𝑥𝑡

𝑥

(3.24)

Similarly the summation of forces along the 𝑂𝑚𝑌𝑚 axis:

∑ ∑ 𝐹⋆◊𝑦


= −𝑚�̈�𝐺𝐵 + 𝐹𝑒𝑥𝑡

𝑦 (3.25)

Finally, the moments about the vertical axis through the CG, i.e. the 𝑂𝐺𝑍𝑔 axis, are

summed:

∑ {𝐹𝑓◊𝑦

(𝑊𝑏

2− 𝑥𝐺

𝑚) − 𝐹𝑏◊𝑦

(𝑊𝑏

2+ 𝑥𝐺

𝑚)}

◊=𝑙,𝑟

+ ∑ {(𝐹⋆𝑟𝑥 − 𝑅⋆𝑟) (

𝑑𝑚

2+ 𝑦𝐺

𝑚)

⋆=𝑓,𝑏

− (𝐹⋆𝑙𝑥 − 𝑅⋆𝑙) (

𝑑𝑚

2− 𝑦𝐺

𝑚)} + 𝐹𝑒𝑥𝑡𝑦 (𝑝𝑒𝑥 − 𝑥𝐺

𝑚)

− 𝐹𝑒𝑥𝑡𝑥 (𝑝𝑒𝑦 − 𝑦𝐺

𝑚) = 𝐼�̈�𝑚

(3.26)

These last six equations, with the proper substitutions using Equations 3.4-3.20

including desired velocity terms �̇�, �̇�, 𝑎𝑛𝑑 �̇�, create a system of 6 nonlinear equations and

6 unknowns (𝑁𝑓𝑙 , 𝑁𝑓𝑟 , 𝑁𝑏𝑙, 𝑁𝑏𝑟 , �̇�𝑙, �̇�𝑟), which can potentially be solved to determine the

resultant wheel speeds. The equations in MATLAB-ready format are included in Appendix

A for reference.

28

3.3. CLOSED FORM SOLUTION

Multiple solving techniques and software solutions were explored in an attempt to

find a closed-form solution to the general system derived above. Attempts utilized

programs such as MATLAB and Wolfram Alpha, which are ill-suited for a nonlinear

system of this size and Mathematica, which after running for 8 continuous days was

eventually terminated without a solution. To better understand the scope of the required

task, the system was simplified to 4 equations and 4 unknowns, using Equations 3.21-3.24

and solving for only the normal forces. While this did give a result after a few minutes, the

equations contained over 140 lines of output and could not be intuitively interpreted. This

result further indicated that the exponential increase possibly induced by introducing two

more equations and unknowns might be insoluble. The likely culprits are the nonlinearities

in the friction equations, a common thorn in the side of any researcher who must account

for friction in a non-negligible way.

3.4. NUMERICAL SOLVERS

The method employed by Liu and Liu was to utilize numerical solutions to process

their system of equations, although the details of such implementation were not provided.

The model was then used in a series of simulations in order to validate their approach.

While a valid approach for simulation when time constraints are not an issue, real-time

implementation is another matter. Initial tests with numerical solvers on the VaultBot

system of equations, using MATLAB’s fsolve tool, resulted in a ~70 second solve time.

While this number could undoubtedly be improved with careful optimization, it is much

less certain that it could be improved by 3 orders of magnitude, which would be necessary

for real-time implementation. Therefore, no further consideration was taken on this

approach.

29

3.5. SUMMARY

By developing a thorough, analytical model, the goal was to obtain a sound

theoretical basis explaining and correcting for the unique behavior exhibited by the

VaultBot. Unfortunately, the non-linear friction behavior proved to be a significant driving

factor in the platform’s behavior, which resulted in an untenable closed-form solution.

Numerical solvers also struggled with the model, with the attempted implementations

being much too slow for real-time usage. However, it should be noted that very little

optimization was performed and a closer look at better solver implementation may be a

good candidate for future work.

30

Chapter 4: Empirical Solutions

With solution of the full analytic model proving impractical, another general

approach is experimentation and data analysis. This chapter will discuss two approaches,

one of which utilized a Vicon motion capture system to obtain data for a neural network,

and the other of which repurposed odometry-less SLAM techniques to track relative

motion and generate data for a heuristic model. The former ultimately proved unsuccessful,

while the latter provided promising results. Note that the data measurement techniques and

analysis techniques are not coupled to each other out of necessity, but rather as a result of

lessons learned and improvements made.

4.1. NEURAL NETWORK

The first empiric approach was to collect sufficient amounts of experimental data

to be able to map the VaultBot’s actual behavior to desired velocity inputs and CG location

using a neural network. This required accurate location tracking of the mobile system’s

position over time, using a method not dependent on the flawed odometry model of the

VaultBot, which suggested use of an external motion tracking system.

4.1.1. Vicon Motion Tracking

Courtesy of Dr. Ufuk Topcu and Timothy Lowery of the University of Texas

Aerospace department, the VaultBot was able to run a series of experiments in the Vicon

lab at the W.R. Woolrich labs building on UT’s main campus. Primarily used for tracking

the motion of small, fast agents such as quadcopters, the Vicon system [34] utilizes several

small retroreflective markers and a large, redundant array of infrared sensors to track the

location of an object over time with great accuracy. Four of these markers were placed on

31

the VaultBot in strategic locations as to not be obscured by the manipulator arms, and to

create a coordinate frame with an origin approximately coincident with the geometric

center of the wheel base, at floor level.

Figure 4-1: VaultBot with Vicon Retroreflective Markers

This accurate location tracking provided by the Vicon system would create a “truth”

model for any maneuvers, and provide a set of output behaviors for the neural network to

map to the input commands of desired linear and angular velocities and input parameters

of CG location.

32

4.1.2. Implementation

The plan was to command the VaultBot through a series of open-loop trajectories:

an in-place rotation maneuver, a straight line maneuver, two separate “arc” maneuvers with

different combinations of constant linear and angular motion, and two “s-curve” maneuvers

with varying combinations of constant linear and dynamic angular motion. These

trajectories would be tested with 7 different arm configurations, and thus 7 different CG

locations, to compare the effects of a dynamic CG on the vehicle’s behavior. Unfortunately,

the room in which the Vicon system was installed, being primarily designed for quadcopter

tracking, had a floor of low-pile carpet. While the hope was that this would not affect the

VaultBot’s motion greatly, the added friction complicated issues significantly. Several

combinations of arm locations and trajectories, such as in-place rotations with the arms

anywhere close to the body, were unfeasible because the VaultBot would begin bouncing

back and forth on its tires rather than sliding smoothly along the floor. Nevertheless,

approximately 75 tests were performed and the data obtained from those tests was analyzed

and post-processed.

4.1.3. Results

To build a neural network, nftool [35] in MATLAB was utilized. The data from

the tests was accumulated and the network was setup to build a connection between 5 inputs

and 2 outputs. The 5 inputs were the x and y coordinates of the CG, and the three velocity

components �̇�, �̇�, �̇� as measured by the Vicon system. The outputs were the wheel speeds

as measured by the encoders. However, despite several attempts the resultant models were

all quite poor. They showed no flexibility to inputs other than the training data itself, and

in that case they generally performed poorly as well. In hindsight, despite all the tests which

were performed the input data was still likely much too small to form a decent model. Also,

33

even if the network had been successful it would have been a “black box” solution, with

no ability to draw meaningful connections and understanding from the result. This would

prevent any further expansion of the model to accommodate additional parameters, such

as floor surface, without simply re-training the model with untenable amounts of further

experimentation. Due to the prospect of excessive wear and tear on the vehicle from a high

and yet unknown number of necessary experiments, this method was not further pursued.

4.2. HEURISTIC MODEL

A closed-form or numerical solution of the full kinematic model proved infeasible

due to its complexity, and the neural network intractable due to its “black box” effect and

need for excessively high experimentation volume. Thus, a third approach was devised as

a hybrid of the previous two efforts. Development of a heuristic model based on analyses

of trajectories allowed for insights into the physical behavior of the system, while providing

feasible implementation and control over a flexible experimentation volume. The goal of

the model is to find the actual center-of-rotation’s location relative to the geometric center

of the mobile system for any given CG location, model the CoR as having traditional

differential behavior, and then solve for the motion of the geometric center given the CoR’s

actual location. Also, the model will adjust for increased or decreased turning speed due to

the CG location.

4.2.1. Experimental Setup

The tests were performed in the Nuclear and Applied Robotics Group lab facilities

at JJ Pickle Research Campus, on a smooth concrete floor typical of warehouses and other

industrial settings. In order to provide a baseline for the model, the VaultBot was asked to

repeat a single open-loop trajectory, specifically an in-place counter-clockwise rotation at

34

0.3 rad/s for 5 seconds, with a different center-of-gravity location for each iteration.

Previous testing indicated that the farther the CG was from the geometric center of the

vehicle, the faster the robot would actually rotate given a fixed desired rotation speed.

Therefore, the desired speed of 0.3 rad/s was chosen so that the increased speeds at the

extremes would not interfere with the tracking system. Also of note is that the VaultBot

consistently performed worse when asked to execute an equivalent clockwise in-place

rotation, often resulting in rocking and bouncing back and forth on the tires rather than

sliding cleanly in the xy-plane. The cause for this has yet to be determined. Assuming the

CG lies on the x-axis (as it does in the performed experiments), the performance should be

identical regardless of the direction of rotation. One possible reason for this is the

asymmetry in the tire treads; however this is simply conjecture and further study is

warranted. For the purposes of developing the heuristic model, however, the assumption is

made that in the ideal case counter-clockwise and clockwise rotations behave

symmetrically and that a reasonable model can be extracted from tests of a single rotational

direction.

4.2.1.1. Hector SLAM

In order to track the truth trajectory of the VaultBot in the absence of a Vicon or

other similar motion-tracking system, a package called Hector SLAM [36] was utilized.

Leveraging the high resolution and reliability of industrial LIDAR systems, Hector SLAM

ignores any odometry input and provides an accurate map and system localization using

only the laser scans. Since Hector SLAM is independent of the VaultBot’s flawed

odometry, it is an ideal solution for system localization with a previously unknown map,

and is the algorithm of choice for such behaviors. By restarting Hector SLAM before each

35

test, the system was able to create a local map and accurately track its rotation behavior

with relatively little noise and no drift errors.

Given its exceptional performance in the SLAM scenario, the question then arises:

why not utilize Hector SLAM for general navigation purposes? Unlike probabilistic,

particle filter navigation models such as AMCL which populate a “cloud” of guesses,

Hector SLAM maintains a single estimate of the robot’s location at any given time. This

works in the SLAM case because, since a new map is being built, it is known with absolute

certainty that the initial location is 100% correct. Also, SLAM processes are usually not

fully autonomous, but rather driven by a human tele-operator who can ensure that motions

are continuous, steady, and sufficiently slow. If this behavior is violated, the single estimate

model can be prone to sudden, discrete jumps which invalidate the data. This model is also

generally helpless in the “kidnapped robot case”, where the agent is suddenly moved to a

different location while being unable to track the transition (for example, if the LIDAR

data is interrupted for any significant length of time). Hector SLAM in its current

implementation also cannot localize within a known map, nor does it handle dynamic

obstacles well as it will add them into the map if seen for a sufficient length of time. It is

possible that principles from Hector SLAM could be leveraged into developing a new,

improved navigation model, and is worth of future study, but it is not the focus of this

effort.

4.2.1.2. Center-of-Gravity Solver

In order to observe the effects of a changing center-of-gravity on the VaultBot’s

behavior, a grid of CG locations was created and the same open-loop rotation was

performed for each location. The x-coordinate for the CG was from -0.06m to 0.12m with

a resolution of 0.02m, and the y-coordinate was from -0.03m to 0.03m with a resolution of

36

0.01m. This created a rectangular grid of 68 points, with the exceptions being at (0.12,

0.03) and (0.12, -0.03) which were unobtainable with the arms’ limited reach.

In order to calculate the CG for any given manipulator pose, the CG for the locally

static portion of the system needed to first be determined. Due to the amount of

modifications and additions to the original husky system, it was decided that an

experimental approach would be the most accurate. To carry out the experimental

approach, the VaultBot’s arms were moved to the standard stow configuration and then the

robot was placed on 4 industrial scales with one under each wheel. The following statics

calculation was then performed with the 4 values to determine the X component of the CG,

and repeated likewise for the Y component:

𝑥𝐺𝑚 =

∑ ∑ 𝑚⋆◊𝑥⋆◊𝑚


∑ ∑ 𝑚⋆◊◊=𝑙,𝑟⋆=𝑓,𝑏 (4.1)

where 𝑚⋆◊ refers to the measured mass at each scale, and 𝑥⋆◊𝑚 refers to the coordinate

location of each wheel’s contact point relative to the geometric center of the vehicle. Due

to slight variations in the scale readings, this was repeated 4 times, with the robot lifted off

and then replaced on the scales each time. The 5 values were then averaged for the final

result. Using the Denavit-Hartenberg[37] parameters for the UR5 arms and the CG values

for each joint as provided by Universal Robotics[38], forward kinematics were calculated

to find the composite CG and mass total for the two arms in the standard stow

configuration. This was subtracted from the experimental result to solve for the CG and

mass value of the static portion of the system.

With the static mass information known, the composite CG for any given arm

configuration can then be calculated analytically. To do this, forward kinematics are again

37

utilized to find the CG and mass values of the dynamic components which are then added

to the static values. Obtaining a configuration which resulted in the desired CG location

for each test was then simply a matter of manually moving the arms, updating the CG

calculation, and repeating until sufficiently close. The large discrepancy in degrees of

freedom between the dynamic elements (12, in the two mobile manipulators) and the

desired output (3, CG position) results in a near-infinite number of solutions for any desired

CG position, which encouraged the manual approach.

4.2.1.3. Center-of-Rotation

To find the CoR given an arc trajectory, the start and final points of the trajectory

are mapped with a rotation matrix based on the change in heading:

[𝑥𝑓 − 𝑐𝑥

𝑦𝑓 − 𝑐𝑦] = [

𝑐Δ𝜃 −𝑠Δ𝜃𝑠Δ𝜃 𝑐Δ𝜃

] [𝑥𝑠 − 𝑐𝑥

𝑦𝑠 − 𝑐𝑦] (4.2)

𝛥𝜃 = 𝜃𝑓 − 𝜃𝑠, 𝜃𝑠 = 0, ∴ 𝛥𝜃 = 𝜃𝑓 = 𝜃 (4.3)

where the position and heading data for the start point is represented as (𝑥𝑠, 𝑦𝑠, 𝜃𝑠)., and

the data for the final point is given as (𝑥𝑓 , 𝑦𝑓 , 𝜃𝑓). Then solving for the CoR coordinates

(𝑐𝑥, 𝑐𝑦) gives:

𝑥𝑓 − 𝑐𝑥 = 𝑐𝜃(𝑥𝑠 − 𝑐𝑥) − 𝑠𝜃(𝑦𝑠 − 𝑐𝑦), 𝑦𝑓 − 𝑐𝑦 = 𝑠𝜃(𝑥𝑠 − 𝑐𝑥) + 𝑠𝜃(𝑦𝑠 − 𝑐𝑦)

𝑐𝑥 = −𝑥𝑓 + 𝑥𝑠 − 𝑥𝑓𝑐𝜃 − 𝑥𝑠𝑐𝜃 − 𝑦𝑓𝑠𝜃 + 𝑦𝑠𝑠𝜃

2(𝑐𝜃 − 1) (4.4)

𝑐𝑦 = −𝑦𝑓 + 𝑦𝑠 − 𝑦𝑓𝑐𝜃 − 𝑦𝑠𝑐𝜃 + 𝑥𝑓𝑠𝜃 − 𝑥𝑠𝑠𝜃

2(𝑐𝜃 − 1) (4.5)

38

4.2.2. Model Setup

Treating the CoR as having a traditional, differential model, and adding in a factor

𝑘 to account for increased or decreased turning speed due to the CG location yields:

�̇�𝐶𝑅𝑚 =

𝑟(�̇�𝑙 + �̇�𝑟)

2 (4.6)

�̇�𝐶𝑅𝑚 = 0 (4.7)

�̇�𝐶𝑅𝑚 =

1

𝑑𝑚𝑤𝑠

[𝑟(�̇�𝑟 − �̇�𝑙)] ⋅ 𝑘 (4.8)

�̇�𝑙 =1

𝑟(�̇�𝐶𝑅

𝑚 −𝑑𝑚𝑤𝑠�̇�𝐶𝑅

𝑚

2𝑘) (4.9)

�̇�𝑟 =1

𝑟(�̇�𝐶𝑅

𝑚 +𝑑𝑚𝑤𝑠�̇�𝐶𝑅

𝑚

2𝑘) (4.10)

The geometric center and CoR share the same rotational velocity. The relationship

between the linear velocities are:

�̇�𝑚𝐵 = �̇�𝐶𝑅

𝑚 + �̇�𝐶𝑅𝑚 𝑦𝐶𝑅

𝑚 (4.11)

�̇�𝑚𝐵 = �̇�𝐶𝑅

𝑚 − �̇�𝐶𝑅𝑚 𝑥𝐶𝑅

𝑚 (4.12)

�̇�𝑚𝐵 = �̇�𝐶𝑅

𝑚 (4.13)

Therefore, the dynamics of the geometric center can be modeled as follows:

�̇�𝑚𝐵 =

𝑟(�̇�𝑙 + �̇�𝑟)

2+

1

𝑑𝑚𝑤𝑠

[𝑟(�̇�𝑟 − �̇�𝑙)] ⋅ 𝑘 ⋅ 𝑦𝐶𝑅𝑚 (4.14)

�̇�𝑚𝐵 = −�̇�𝑚

𝐵 𝑥𝐶𝑅𝑚 = −

1

𝑑𝑚𝑤𝑠

[𝑟(�̇�𝑟 − �̇�𝑙)] ⋅ 𝑘 ⋅ 𝑥𝐶𝑅𝑚 (4.15)

�̇�𝑚𝐵 =

1

𝑑𝑚𝑤𝑠

[𝑟(�̇�𝑟 − �̇�𝑙)] ⋅ 𝑘 (4.16)

39

Note that since �̇�𝑚𝐵 is non-zero, the system is now overdetermined. To solve for the

wheel speeds therefore, only equations 4.14 and 4.16 are utilized:

�̇�𝑙 =1

𝑟(�̇�𝑚

𝐵 − �̇�𝑚𝐵 𝑦𝐶𝑅

𝑚 −�̇�𝑚

𝐵 𝑑𝑚𝑤𝑠

2𝑘) (4.17)

�̇�𝑟 =1

𝑟(�̇�𝑚

𝐵 − �̇�𝑚𝐵 𝑦𝐶𝑅

𝑚 +�̇�𝑚

𝐵 𝑑𝑚𝑤𝑠

2𝑘) (4.18)

Given the circumstances, this is the most logical solution to the overdetermined

system. Out of the three possible control inputs only two can be utilized, and �̇�𝑚𝐵 and �̇�𝑚

𝐵

are the two most intuitive control inputs from an operator’s perspective. However, this also

reveals the inherent challenge with controlling the VaultBot platform. As long as 𝑥𝐶𝑅𝑚 is

non-zero �̇�𝑚𝐵 is also non-zero, and if �̇�𝑚

𝐵 is non-zero then the system is not fully controllable.

Therefore, while steps such those described in this section can be made to improve the

model, perfect open-loop trajectory tracking is unattainable.

4.2.3. Results

As the tests were performed, all relevant data was logged using the rosbag utility

and then post-processed, analyzed, and plotted using python. The in-place rotation tests

40

immediately demonstrated significant variance in the VaultBot’s behavior dependent on

the position of its CG.

Figure 4-2: In-Place Rotation Position Tracking, COM-y position @ 0.02

Figure 4-2 shows a sample of 10 of the 68 tested CG locations, in this case with the

Y-coordinate held constant at 0.02m, and the X-coordinate varied from -0.06m to 0.12m.

41

The rectangle outline shows the wheel base of the VaultBot for scale, and recall that the

coordinate system is oriented such that the floor is parallel to the XY-plane and the x-axis

positive direction points towards the front of the robot. Each colored line represents the

location of the geometric center of the vehicle over time, while the matching color small

circles show the position of the CG for that test. Heading information is not directly shown

on the plot, but can be roughly inferred from the trajectories and knowledge of the direction

of rotation (CCW). Exact heading data was used along with the trajectories in equations

4.19 and 4.20 to solve for the approximate CoR for each point along the trajectory,

represented by the colored diamonds:

𝑥𝐶𝑅

𝑘 = −(𝑥𝑓𝑘 + 𝑥𝑠 − 𝑥𝑓

𝑘 cos(𝜙) − 𝑥𝑠 cos(𝜙) − 𝑦𝑓𝑘 sin(𝜙)

+ 𝑦𝑠 sin(𝜙))/(2 cos(𝜙) − 2) (4.19)

𝑦𝐶𝑅

𝑘 = −(𝑦𝑓𝑘 + 𝑦𝑠 − 𝑦𝑓

𝑘 cos(𝜙) − 𝑦𝑠 cos(𝜙) − 𝑥𝑓𝑘 sin(𝜙)

+ 𝑥𝑠 sin(𝜙))/(2 cos(𝜙) − 2) (4.20)

where 𝑥𝑠 and 𝑦𝑠 are the coordinates of the trajectory starting location and 𝑥𝑠𝑘 and 𝑦𝑠

𝑘 are

the coordinates of each successive trajectory point, only applying this to points where 𝑘 >

50 to eliminate noise. As these clusters reliably showed a trend of converging over time,

42

the final point was selected as the CoR for the whole trajectory, and was highlighted using

a larger circle of the appropriate color.

Figure 4-3: In-Place Rotation Smoothed Angular Velocities, COM-y position @ -0.03

The rotational velocity for each test was also calculated by dividing the change in

heading data by the sample time for each interval, and then smoothing the result with a

43

moving average. Figure 4-3 shows the results for the set of tests with a constant Y-

coordinate value of -0.03m. This shows that, after an initial acceleration, each trajectory

maintains a fairly consistent velocity over time. The values from these plateaus were then

averaged to find an approximation for the whole trajectory’s average rotational velocity.

Table 4-1: Average Rotational Velocity Ratio to Cmd. Velocity

The average rotational velocity values were then divided by the command velocity

of 0.3 rad/s to obtain an error ratio and then tabulated, as seen in Table 4-1.

0.3 CG_x -0.06 -0.04 -0.02 0 0.02 0.04 0.06 0.08 0.1 0.12

CG_y Avg Std. Dev.

0.03 1.120 1.023 0.963 0.947 0.960 1.017 1.087 1.247 1.443 1.090 0.163

0.02 1.107 1.020 0.977 0.963 0.977 1.013 1.090 1.283 1.500 1.603 1.153 0.231

0.01 1.120 1.027 0.980 0.967 0.983 1.037 1.117 1.273 1.480 1.607 1.159 0.224

0 1.120 1.027 0.987 0.973 0.983 1.033 1.113 1.290 1.480 1.597 1.160 0.222

-0.01 1.120 1.037 0.987 0.970 0.980 1.013 1.097 1.280 1.533 1.620 1.164 0.237

-0.02 1.117 1.017 0.970 0.960 0.977 1.013 1.103 1.267 1.503 1.607 1.153 0.232

-0.03 1.107 1.013 0.970 0.960 0.970 0.993 1.097 1.273 1.500 1.098 0.181

Avg 1.116 1.023 0.976 0.963 0.976 1.017 1.100 1.273 1.491 1.607

Std. Dev. 0.006 0.008 0.009 0.009 0.008 0.014 0.011 0.014 0.028 0.008

Avg

. Rot

. Vel

ocit

y R

atio

to

Cm

d.

44

Figure 4-4: Average Rotational Velocity Error Ratios vs. CG position

Figure 4-5: Average Rotational Velocity Error Ratios vs. CG x-position

The error ratios were then plotted against their CG position in Figure 4-4. This

indicates a strong dependence on the x-coordinate and independence with the y-coordinate

45

of the CG. Therefore, in Figure 4-5 the values were grouped by CG y-position and plotted

against the CG x-position, then fitted with a polynomial trendline matched to the averaged

values. Since the values plotted were the ratio of the actual rotation to the commanded

rotation, the equation of this trendline then gives a basis for the rotation scaling factor 𝑘:

𝑘 = (46.902 ⋅ 𝑥𝐺𝑚2

+ 0.1056 ⋅ 𝑥𝐺𝑚 + 0.9541)/1.875 (4.21)

Note that the equation has the default Clearpath “wheel separation multiplier” of

1.875 folded into it. Accounting for this multiplier is necessary because it is utilized in the

default controller, which was used to run the experiments. Folding it into 𝑘 allows resetting

the multiplier to 1.0, which is a good baseline for any necessary further tuning.

Table 4-2: Center-of-Rotation x-position for given Center-of-Gravity

The same procedure was utilized to compare the relationship between the

VaultBot’s center-of-gravity and its center-of-rotation. However, with a two dimensional

output, the two output elements (CoR x and y positions) were split and analyzed separately.

Table 4-2 shows the data for the CoR x-positions with a given CG location.

CG_x -0.06 -0.04 -0.02 0 0.02 0.04 0.06 0.08 0.1 0.12

CG_y Avg. Std. Dev.

0.03 -0.197 -0.156 -0.112 -0.076 -0.012 0.035 0.081 0.125 0.162 -0.017 0.127

0.02 -0.197 -0.152 -0.105 -0.054 -0.016 0.025 0.082 0.135 0.159 0.174 0.005 0.132

0.01 -0.196 -0.15 -0.096 -0.054 -0.009 0.044 0.082 0.128 0.161 0.171 0.008 0.130

0 -0.193 -0.163 -0.113 -0.066 -0.027 0.024 0.078 0.124 0.157 0.171 -0.001 0.132

-0.01 -0.198 -0.154 -0.111 -0.066 -0.022 0.013 0.068 0.131 0.158 0.172 -0.001 0.132

-0.02 -0.204 -0.151 -0.104 -0.049 -0.019 0.027 0.073 0.122 0.159 0.171 0.003 0.131

-0.03 -0.202 -0.162 -0.115 -0.073 -0.029 0.015 0.068 0.121 0.161 -0.024 0.126

Avg -0.198 -0.155 -0.108 -0.063 -0.019 0.026 0.076 0.127 0.160 0.172

Std. Dev 0.004 0.005 0.007 0.010 0.007 0.011 0.006 0.005 0.002 0.001

CoR

x-p

osit

ion

46

Figure 4-6: Center-of-Rotation x-position vs. Center-of-Gravity position

Figure 4-7: Center-of-Rotation x-position vs. Center-of-Gravity x-position

y = 2.1722x - 0.0635R² = 0.9931

-0.25

-0.2

-0.15

-0.1

-0.05

0

0.05

0.1

0.15

0.2

0.25

-0.08 -0.06 -0.04 -0.02 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14

CoR x-position vs. CG x-position (m)

0.03 0.02 0.01 0 -0.01 -0.02 -0.03 Average

47

Similarly to the rotational velocity analysis, the 3D chart given in Figure 4-6 shows

a strong dependence of the CoR’s x-coordinate with the CG x-position, and a strong

independence from the CG y-position. Therefore, a simple heuristic equation can be

extracted from the trendline in Figure 4-7 to solve for the x-coordinate of the CoR:

𝑥𝐶𝑅𝑚 = 2.1722 ⋅ 𝑥𝐺

𝑚 − 0.0635 (4.22)

Table 4-3: Center-of-Rotation y-position for given Center-of-Gravity

CG_x -0.06 -0.04 -0.02 0 0.02 0.04 0.06 0.08 0.1 0.12

CG_y Avg. Std. Dev.

0.03 -0.021 -0.04 -0.056 -0.05 -0.049 -0.05 -0.046 -0.043 -0.032 -0.043 0.011

0.02 -0.015 -0.022 -0.032 -0.032 -0.04 -0.045 -0.053 -0.039 -0.022 -0.01 -0.031 0.014

0.01 0.009 -0.007 -0.014 -0.012 -0.029 -0.038 -0.039 -0.039 -0.014 -0.007 -0.019 0.016

0 0.01 0.009 0.008 0.001 -0.006 -0.015 -0.017 -0.023 -0.022 -0.01 -0.007 0.013

-0.01 0.027 0.021 0.017 0.015 0.012 0.006 0.007 -0.001 -0.008 -0.004 0.009 0.011

-0.02 0.051 0.034 0.037 0.03 0.026 0.026 0.013 0.004 -0.01 -0.005 0.021 0.020

-0.03 0.048 0.053 0.046 0.047 0.044 0.039 0.02 0.012 -0.003 0.034 0.020

Avg 0.016 0.007 0.001 0.000 -0.006 -0.011 -0.016 -0.018 -0.016 -0.007

Std. Dev 0.028 0.032 0.037 0.034 0.035 0.036 0.030 0.023 0.010 0.003

CoR

y-p

osit

ion

48

Figure 4-8: Center-of-Rotation y-coordinate vs. Center-of-Gravity location

Figure 4-9: Center-of-Rotation y-coordinate vs. Center-of-Gravity x-coordinate

49

Figure 4-10: Center-of-Rotation y-position vs. Center-of-Gravity y-position

As can been seen in Table 4-3 and Figure 4-8 - Figure 4-10, the relationship

between the CoR y-coordinate and the CG location is not as simple as previously examined

correlations. At this point, due to the apparent dependence on two variables rather than just

one, several approaches were taken. The first approach was to utilize the built-in

multivariate regression analysis from Microsoft Excel [39].

Table 4-4: Multivariate Regression of CoR y-position for given CG, part 1

Regression Statistics

Multiple R 0.92588449

R Square 0.857262088

Adjusted R Square 0.852870153

Standard Error 0.011301514

Observations 68

50



Figure 4-11: Multivariate Regression of CoR y-position for given CG; Results

At first glance, a very low significance F value (Table 4-5) and decent R values

(Table 4-4) indicate that the multivariate regression is a good fit for the data. The

coefficients in Table 4-6 then result in the following equation solving for the y-coordinate

of the CoR:

𝑦𝐶𝑅𝑚 = −0.166 ⋅ 𝑥𝐺

𝑚 − 1.295 ⋅ 𝑦𝐺𝑚 − 0.0006 (4.23)

ANOVA

df SS MS F Significance F

Regression 2 0.049860985 0.02493 195.190034 3.33065E-28

Residual 65 0.008302074 0.000128

Total 67 0.058163059

Coefficients Standard Error t Stat P-value Lower 95% Upper 95% Lower 95.0% Upper 95.0%

Intercept -0.000571511 0.001524523 -0.37488 0.70897122 -0.003616194 0.002473172 -0.003616194 0.002473172

CG_x -0.166202827 0.024411906 -6.80827 3.7791E-09 -0.214956769 -0.117448885 -0.214956769 -0.117448885

CG_y -1.295038168 0.069820984 -18.548 1.1692E-27 -1.434480302 -1.155596034 -1.434480302 -1.155596034

51

However, when observing Figure 4-11 it becomes clear that the regression does a

poor job of modeling the convergence of the CoR y-coordinate to zero when the CG x-

coordinate increases to 0.12. The orange markers indicate the predicted CoR y-values given

the fixed inputs using the regression model, while the blue markers show the

experimentally measured positions.

A second approach was a two-step method leveraging the apparent linearity of the

data sets in Figure 4-10. As is shown, each data set was fit with a linear trendline.

Table 4-7: Equation Coefficients for Linear Regression of Figure 4-10 data

The coefficients of the linear trendlines were then tabulated based on the CG x-

position, which was the feature that differentiated the data sets in Figure 4-10. These

coefficients were then plotted separately against the CG x-position and fit with polynomial

trendlines of their own:

CG-x -0.06 -0.04 -0.02 0 0.02 0.04 0.06 0.08 0.1 0.12

Slope -1.275 -1.4964 -1.6964 -1.5786 -1.6143 -1.6179 -1.3429 -1.0321 -0.4179 -0.13

Intercept 0.0156 0.0069 0.0009 -0.0001 -0.006 -0.011 -0.0164 -0.0184 -0.0159 -0.0072

52

Figure 4-12: Slopes of Linear Regressions from Figure 4-10 vs. CG x-position

Figure 4-13: Intercepts of Linear Regressions from Figure 4-10 vs. CG x-position

Combining these equations with the linear model from the first step results in the

following equation for the CoR y-coordinate:

53

𝑦𝐶𝑅

𝑚 = (115.18 ⋅ 𝑥𝐺𝑚2

− 0.2808 ⋅ 𝑥𝐺𝑚 − 1.6955) ⋅ 𝑦𝐺

𝑚

+ (1.5852 ⋅ 𝑥𝐺𝑚2

− 0.2512 ⋅ 𝑥𝐺𝑚 − 0.0043)

(4.24)

This model results in a significantly better mapping to the observed data, as can be

seen in Figure 4-14.

Figure 4-14: Predicted vs. Measured CoR y-position with Full Model

However, the model also reveals a bias to one side which is due to either the

direction of rotation, or un-modeled asymmetry in the VaultBot’s behavior, perhaps due to

the arrangement of the tire treads. In the interest of a more general solution, and since clean

measurements of the other direction of rotation are unfeasible as previously discussed,

another model was developed to remove the asymmetry.

𝑦𝐶𝑅𝑚 = (115.18 ⋅ 𝑥𝐺

𝑚2− 0.2808 ⋅ 𝑥𝐺

𝑚 − 1.6955) ⋅ 𝑦𝐺𝑚 (4.25)

54

Simply by removing the intercept term of Equation 4.24, a new model is created

which is symmetric about the x-axis.

Figure 4-15: Predicted vs. Measured CoR y-position with Symmetric Model

Figure 4-15 compares the predicted values from the symmetric model with the

measured experimentation data. The symmetric model is less well mapped to the

experimental data when compared to the full model, but it is a more elegant and perhaps

more general solution.

55

4.3. CONCLUSIONS & IMPLEMENTATION

From simple observation of the VaultBot’s behavior, it seems intuitive that the

vehicle rotates about the location of its CG when attempting an in-place rotation. However,

analysis of the experimental data reveals this is not the case. Equation 4.22 shows that the

x-coordinate of the CoR scales linearly with the CG x-coordinate, along with having a

constant offset. The scaling factor reflects the complex slip interactions resulting from the

shifting normal forces, and its sign concurs with logical intuition; if the CG were to

coincide with either the front or rear axis, the VaultBot would be expected to behave like

a differentially steered vehicle at that axis, with the other axis having very little effect on

the motion. This would also suggest that the linear model would break down as the CG

approaches these extremes, and close analysis of Figure 4-7 shows that this may be the

case, with all points at 𝑥𝐺𝑚 = 0.012 beginning to tail off below the trendline. Within the

operational reach of the manipulators however, the linear model holds strong. The constant

offset likely reflects the rotational inertia of the mobile manipulator. Due to the forward

positioning of the arm mount locations, a configuration which results in a forward shift of

the CG tends to have a higher rotational inertia than a configuration resulting in an

equivalent backwards shift. Further study to better understand the rotational inertia’s effect

on the system’s behavior is warranted.

Figure 4-5 also shows that as the CG shifts forward or backwards towards the

extremes, the angular velocity of the VaultBot increases. The reason for this is intuitive.

As the mass becomes unbalanced towards one end of the vehicle, the slips in the wheels at

that end decrease until they are theoretically zero, when the mass is directly centered over

the axis and the dynamic model matches that of a differentially steered platform.

Conversely, the decrease in normal forces at the opposing end leads to a significant increase

56

in slip and decrease in lateral friction, until the extreme case when there is theoretically no

lateral friction at all to oppose the rotational motion imposed by the primary wheel axis.

Somewhat counterintuitively, the y-coordinate of the center-of-rotation scales

inversely with the y-coordinate of the center-of-gravity. Once again consideration of the

extreme case, here with the CG directly aligned with either the left or right wheels, clarifies

the behavior.

Figure 4-16: CoR behavior with varying CG y-coordinate

Alignment with the left wheels is the situation considered in Figure 4-16, part A.

In this ideal case, the normal forces on the opposite wheels would be zero and the vehicle

57

would travel straight, only having driving contribution from the left set of wheels. Thus,

the CoR would exist at ±∞, and the system would behave much like a bicycle with a fixed

steering column. However, since the CoR can exist at either positive or negative infinity,

this does not clarify the relationship between it and the CG. For that, we consider the case

in Figure 4-16, part B. Here we have moved the CG ever so slightly to the right, to the

inside of the left wheels. This introduces very small normal force interactions at the right

wheels which we treat as negligible as to continue the bicycle analogy. A bicycle with a

fixed steering column and a slightly offset center of gravity will gradually turn to that side,

so we can identify the CoR’s location to be at some large, positive value that is less than

infinity. Therefore, it appears that the CG and CoR trend in opposite directions and come

to their logical conclusion in part C, the most basic case where they are coincident and the

vehicle exhibits ideal in-place rotation. Nevertheless, within the operating range of the

manipulators the differential behavior resulting from a forward or backward shift in the CG

is the dominating factor. The effect of the y-coordinate of the CG is greatly diminished

when the x-coordinate is largely positive or negative.

To implement these heuristic equations, a new ros_control package was

created named skid_steer_controller, closely derived from

diff_drive_controller. The controller was expanded to allow for y-velocity

tracking in the odometry, and Equations 4.14-4.18 were utilized to replace the primary

odometry and wheel speed calculations. Equations 4.21-4.22 were implemented to solve

for new parameters 𝑘 and 𝑥𝐶𝑅𝑚 , respectively, while Equations 4.23-4.25 were utilized to

solve for 𝑦𝐶𝑅𝑚 subject to an adjustable selection parameter, with the default set to Equation

4.25 which is most consistent with the symmetry assumption discussed in Section 5.2.1.

58

Chapter 5: Demonstration

5.1. SETUP

In order to experimentally validate the new controller, a rigorous set of experiments

with varying CG positions and varying command trajectories was devised. 7 different arm

configurations and 6 different open-loop trajectories were combined for a total of 42

experiments, with the goal of obtaining a sufficiently representative spread of CG positions

and dynamic scenarios. This set of experiments was also run twice, once with the default

diff_drive_controller, and once with the new skid_steer_controller for

a grand total of 84 experiments.

Figure 5-1: Centers of Gravity for Controller Tests

59

The resultant centers of gravity from the 7 arm configurations are shown in Figure

5-1, while the trajectories consisted of a simple in-place rotation:

“Rotate” 𝑣𝑥 = 0 𝑚/𝑠

�̇� = 0.3 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 5.0𝑠 (5.1)

an “S-curve” trajectory, with a constant forward velocity and a sinusoidal rotational

velocity:

“S-curve”

𝑣𝑥 = 0.4 𝑚/𝑠

�̇� = 0.5 ∗ sin (2𝜋𝑡

9.0) 𝑟𝑎𝑑/𝑠

} 𝑓𝑜𝑟 0 < 𝑡 < 10.0𝑠 (5.2)

And 4 distinct “Arc” behaviors, with constant linear and rotational velocities:

“Arc #1” 𝑣𝑥 = 0.5 𝑚/𝑠

�̇� = 0.1 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 6.0𝑠 (5.3)

“Arc #2” 𝑣𝑥 = 0.5 𝑚/𝑠

�̇� = −0.1 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 6.0𝑠 (5.4)

“Arc #3” 𝑣𝑥 = 0.5 𝑚/𝑠

�̇� = 0.5 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 3.0𝑠 (5.5)

“Arc #4” 𝑣𝑥 = −0.5 𝑚/𝑠

�̇� = 0.1 𝑟𝑎𝑑/𝑠} 𝑓𝑜𝑟 0 < 𝑡 < 6.0𝑠 (5.6)

These tests were again performed on the same smooth concrete floor as the data

collection tests, in the Nuclear and Applied Robotics Group lab facilities at JJ Pickle

Research Campus. Also, Hector SLAM was again used to track the VaultBot’s actual

location over time (see Section 4.2.1.1), and data was collected and processed in ROS

bagfiles.

60

5.2. RESULTS

In order to qualitatively compare the two controllers, each of the 42 CG-position

and trajectory combinations was given its own graph, plotting the true trajectories against

the calculated trajectories for each controller as well as the intended open-loop command

trajectory. The latter was derived by leveraging a pre-existing “updateOpenLoop” method

in the diff_drive_controller, which simply integrates an input of linear and

angular velocities (Equations 5.1-5.6) with the timestep to update a trajectory.

Figure 5-2: Controller Odometry in Scurve Front Left Configuration

61

Figure 5-2 is a clearly interpreted example, showing the case with the arms (and

thus the CG) in the front left position and traversing the s-curve trajectory. The rectangle

in the bottom left of the figure represents the wheelbase of the VaultBot in its starting

configuration. The dark teal circle represents the CG location, while the faded teal diamond

shows the approximate CoR in an in-place rotation case, as derived in Section 4.2. The

gray line is the intended open-loop command, while the solid orange and teal lines are the

actual paths traveled under the diff_drive_controller and the

skid_steer_controller, respectively. The odometry output from each controller is

shown by the dotted lines. Figure 5-3 -Figure 5-5 show more examples in varying CG-

trajectory combinations.

Figure 5-3: Controller Odometry in Arc #2 Back Right Configuration

62

Figure 5-4: Controller Odometry in Rotate Ready Configuration

63

Figure 5-5: Controller Odometry in Arc #4 Ready Back Configuration

From these four examples alone, it is clear that there is significant variation in the

controller performance. Therefore, in order to properly evaluate the performance, it was

necessary to benchmark each configuration against a set of criteria. Particularly in the case

of skid-steer or other insufficiently modeled mobile bases, there are two significant areas

of open-loop error that closed-loop methods must overcome. The first is when the

autonomous agent thinks, via odometry, that it is somewhere it is not. This is represented

in the figures above by the difference between the solid and dotted lines. The greater this

error, the more correction that is necessary from any closed-loop localization methods such

as laser scan based particle filtering or landmark detection. The second area is when the

autonomous agent goes somewhere other than where it was commanded to go. This is

represented by the error between the colored solid lines and the solid gray line. The greater

this error, the more correction that is necessary from closed-loop navigation controllers,

continuously fighting the actual behavior of the robot to try and keep it on course.

Therefore, each configuration was qualitatively analyzed to evaluate whether the

64

skid_steer_controller resulted in needing more, less, or a negligible difference

in closed-loop correction from the diff_drive_controller, and the results were

tabulated in Table 5-1.

Table 5-1: Qualitative Evaluation of Skid-Steer Controller in 42 configurations

Figure 5-2, for example, shows a configuration in which the controller

unfortunately performs objectively worse; there is noticeably greater error in both the new

controller’s estimate of its trajectory compared to the actual and the actual trajectory

compared to the desired open-loop trajectory. Figure 5-4 and Figure 5-5, however, are both

clear successes. In fact, all of the in-place rotations, such as Figure 5-4, were improvements

due to the nature of the default controller. With the CoR assumed to be always coincident

with the geometric center of the wheel base the default controller is not capable of

predicting any behavior other than a simple rotation given no linear velocity input.

Therefore, the odometry output of the default controller is that of pure rotation and differs

greatly from the actual output. The new controller accounts for a variable CoR which

accurately predicts the actual behavior, and so the odometry output and actual trajectory

match very closely. Also, while the new controller is still unable to produce pure rotation,

a close look at the legend in Figure 5-4 shows that the final rotation angle of 82.47 degrees

is a vast improvement over the diff-drive controller’s rotation of 133.39 degrees, when

compared to the desired rotation of 86.70 degrees. These improvements are to be expected

Ready StowBack ReadyBack FrontLeft FrontRight BackLeft BackRight

Arc 1 ↑V, ↑D ↑V, ↑D ↓D ↑V, ↑D ↑V, ↑D ↓V, ↓D ↑D Better 23 ↓V 25

Arc 2 ↓V ↓V, ↑D ↓V, ↓D ↑D ↓V, ↓D ↓V, ↓D ↓V, ↓D Neutral 5 ↑V 8

Arc 3 ↓V, ↑D ↓V ↓V, ↓D ↑D ↓V ↓V, ↓D ↓V Worse 14 ↓D 13

Arc 4 ↑V ↑V ↓V, ↑D ↑V, ↑D ↓D ↓V, ↑D ↑D ↑D 16

Rotate ↓V, ↓D ↓V, ↓D ↓V, ↓D ↓V ↓V ↓V ↓V Invalid Data Set

Scurve ↓V ↓V ↓V, ↑D ↑V, ↑D - ↓V, ↑D ↓D

symbols = less/more (↓/↑) vision/driving (V/D) correction necessary

65

however, as the in-place rotation trajectory was the basis for the skid-steer controller

derivations. In 23 of the 42 configurations, the skid-steer controller was a noticeable

improvement over the default controller. In 5 configurations it had a neutral impact and

either showed a negligible difference or offset between the two criteria. However, in the

other 14 cases the new controller performed noticeably worse. Also of note is that when

the controller showed an improvement, it tended to decrease the vision correction

necessary; i.e. the VaultBot was more accurate in its approximation of where it was

throughout the trajectory. Conversely, it performed worse more often in the area of driving

correction and would deviate further from the desired open-loop trajectory that the skid-

steer controller.

In order to validate the qualitative analysis, a quantitative approach was taken as

well. For the driving comparisons, that is the actual robot path versus the desired open loop

trajectory, two approaches were utilized. First was a direct comparison of the trajectories,

which was done by resampling the trajectories into an equal number of points, calculating

the Euclidean distance between each pair of points, and averaging the result. The lower the

average “drive error”, the better the result. However, this by itself would only tell part of

the story; one could conceivably have a controller with a widely varying trajectory that

ends up very close to the desired end goal, or one that very slightly but consistently deviates

from the desired trajectory to end up far from the goal. Therefore, a second metric was

included to evaluate the end positions. Rather than a simple Euclidean distance, however,

the metric was the requisite time for position correction. This was to account for the fact

that deviation in the x-direction is much easier to correct than deviation in the y-direction

due to the platform’s non-holonomic nature and aversion to in-place rotations. “Correction

time” was calculated with 3 phases: turning towards the goal, driving linearly to the goal,

66

and then rotating again to the correct orientation. The requisite angles of rotation were

divided by the appropriate average rotational velocities for each arm configuration, which

were determined using the known CGs, Equation 4.21, and the in-place rotation control

velocity of 0.3 rad/s. The linear translation was divided by the standard linear velocity of

0.5 m/s. For odometry comparisons, that is the actual robot path versus the calculated robot

path with odometry, only the trajectory comparison technique was utilized. Since the

correcting measures for this error typically rely on continuous correction from closed-loop

vision systems, the trajectory evaluation result was referred to as “vision error”. Also for

this reason the end position correction technique was deemed to not provide additional

insight and was omitted. The quantitative results are presented in Table 5-2 below.

Table 5-2: Quantitative Evaluation of Skid-Steer Controller in 42 configurations

Skid Diff Skid Diff Skid Diff Skid Diff Skid Diff Skid Diff Skid Diff

Drive Error (m) 0.122 0.026 0.034 0.015 0.027 0.047 0.049 0.02 0.052 0.019 0.027 0.046 0.023 0.02

Correction Time(s) 4.03 1.628 3.105 1.277 4.638 3.19 2.154 0.554 3.108 1.119 1.525 3.033 1.595 0.939

Vision Error (m) 0.073 0.031 0.024 0.016 0.073 0.057 0.034 0.015 0.029 0.021 0.019 0.053 0.011 0.021

Drive Error (m) 0.069 0.046 0.038 0.027 0.011 0.065 0.045 0.015 0.031 0.015 0.026 0.036 0.025 0.049

Correction Time(s) 3 3.235 3.287 2.835 0.831 4.534 3.99 2.096 1.084 1.901 1.658 2.743 1.959 3.478

Vision Error (m) 0.038 0.047 0.021 0.036 0.056 0.069 0.025 0.016 0.019 0.018 0.022 0.039 0.013 0.055

Drive Error (m) 0.108 0.055 0.027 0.028 0.055 0.1 0.058 0.034 0.044 0.041 0.032 0.051 0.039 0.033


Vision Error (m) 0.017 0.056 0.014 0.035 0.031 0.101 0.029 0.034 0.017 0.038 0.023 0.055 0.025 0.042

Drive Error (m) 0.072 0.061 0.018 0.026 0.066 0.042 0.052 0.012 0.024 0.045 0.05 0.051 0.046 0.027


Vision Error (m) 0.127 0.064 0.02 0.02 0.031 0.037 0.057 0.01 0.03 0.052 0.018 0.05 0.014 0.024

Drive Error (m) 0.088 0.17 0.059 0.062 0.127 0.162 0.069 0.085 0.031 0.074 0.075 0.089 0.091 0.117


Vision Error (m) 0.042 0.17 0.017 0.062 0.041 0.162 0.046 0.085 0.02 0.074 0.031 0.089 0.031 0.117

Drive Error (m) 0.304 0.229 0.276 0.33 0.208 0.202 0.517 0.41 0.335 0.322 0.344 0.325 0.236 0.312


Vision Error (m) 0.174 0.316 0.041 0.09 0.081 0.244 0.23 0.188 0.204 0.108 0.099 0.121 0.133 0.076

BackRightBackLeftFrontRightFrontLeftReadyBackStowBackReady

Scurve

Rotate

Arc 4

Arc 3

Arc 2

Arc 1

Quantitative Results

67

For each evaluation metric, the controller with the higher score was highlighted

unless the values were too close to call. If the skid-steer controller proved better it was

highlighted in green, while the diff-drive controller was highlighted in red if had better

performance. In most cases the “drive error” and “correction time” were in agreement, but

if they directly opposed then the net result was deemed to be neutral. A close comparison

of these results with the qualitative analysis showed almost agreement across the board,

with two notable exceptions.

Figure 5-6: Controller Odometry in Arc #1 Ready Back Configuration

Qualitative analysis of the Arc 1 trajectory with the “ready back” arm configuration,

see Figure 5-6, determined that the skid_steer_controller had less drive error,

and that both controllers had similar vision error. However, the quantitative results revealed

that while the skid_steer_controller had a better trajectory, it would have an

increased correction time due to the increased requisite rotation angles. Also, quantitative

analysis revealed that the vision error was worse for the skid_steer_controller in

this case.

68

Figure 5-7: Controller Odometry in Arc #2 Front Right Configuration

The Arc 2 trajectory with the “front right” arm configuration in Figure 5-7 also

gave different quantitative results from the qualitative analysis which observed

improvement in both categories with the skid_steer_controller. Quantitative

analysis declared a better end position but a worse trajectory, for a net neutral drive result.

The vision error was too close to call, but in slight favor of the

diff_drive_controller. Excluding the two aforementioned exceptions, however,

the qualitative analysis was strongly corroborated by the quantitative approach.

69

Chapter 6: Conclusions and Future Work

The objective of this thesis was to improve the performance of a unique skid-steer

robotic platform with a dynamic center of gravity. To this end, the

skid_steer_controller was developed out of a heuristic model, as an improvement

upon the traditional diff_drive_controller.

6.1. RESEARCH SUMMARY

The VaultBot is a skid-steer mobile manipulator research platform developed by

the NRG for use in hazardous nuclear applications. A relatively large array of actuators

and sensors is linked together using the Robot Operating System (ROS) networking

software from the Open Source Robotics Foundation, and a variety of packages developed

within that framework to support the individual systems. With two output actuators, one

motor for each side of the robot, the mobile base is configured similarly to a traditional

differential-drive system and thus by default utilizes the ROS navigation stack which is

optimized for use with such systems. In practice, however, there are fundamental

differences between differential steering and skid-steering, primarily as a result of the slip

interactions at the wheels. Additionally, these differences are exacerbated and extended by

the VaultBot’s dynamic center-of-gravity (CG) which is a consequence of the onboard

industrial manipulators. A brief series of experiments, the results of which are shown in

Figure 6-1, illuminated the degree to which output behavior varies given the same input

commands but different CG locations.

70


configuration to color code. (B) “S-curve” trajectory. (C) “Arc” trajectory.

(D) In-place rotation.

In order to develop a better control model based on the CG location, a full kinematic

model of the system was developed. However, this resulted in a system of 6 highly

nonlinear equations with 6 unknowns, to which no closed-form solution could be found. A

cursory look at numeric solvers also did not yield promising results for real-time

implementation, as solutions took an average of 70 seconds. This led to a heuristic

approach in which a grid of 68 different center-of-gravity locations were tested with the

same open loop command, and the resultant trajectories were analyzed for a relationship

between the CG and the apparent center-of-rotation (CoR). This relationship was then

utilized to modify the ROS-based diff_drive_controller package into the

71

skid_steer_controller package. An array of 49 different arm position and open-

loop trajectory configurations were tested with both the new and old controllers in order to

compare results and test for improvement. The results were analyzed both qualitatively and

quantitatively, and both methods came to very similar conclusions.

While the skid_steer_controller was not as drastic of an improvement

as hoped, it did show a net benefit over the diff_drive_controller, particularly in

the in-place rotation behaviors, as well as with the “ready back” and “back left” arm

configurations. Curiously, the diff_drive_controller had consistently better

results with the “front left” arm configuration, for reasons currently unknown. While the

skid_steer_controller is a step in the right direction, there still remains work to

be done.

6.2. FUTURE WORK

In order to further refine the heuristic model, more thorough experimentation could

be performed, with multiple iterations for each CG location and trajectory combination

rather than just one. Also, the model relied on a single in-place rotation trajectory for

development of the CG to CoR relationship; a more robust approach would be to include

multiple trajectory methods. Note that expansion of the experimentation volume is limited

to some extent by physical wear and tear on the robot.

Other approaches also leave room for further work. Working to find a closed-form

solution of the kinematic model could provide a more exact model which could also be

adapted to accommodate additional parameters such as friction coefficients for different

surfaces. This work’s efforts to do so did not yield results after 8 days of computation,

however, so this avenue is not particularly promising. Properly optimized numerical

solvers, on the other hand, may provide an adequate solution. While initial attempts had

72

solve-times well above acceptable limits for real-time implementation, there are a number

of potential approaches to reduce the solve times by one or more orders of magnitude that

have not been fully explored. Whether the reduction is sufficient for real-time operation

remains to be seen.

Finally, while this work focuses on improving the open-loop, odometry side of

skid-steer navigation, there is a large space open for further research into closed-loop

solutions. While the default ROS localization package amcl diverges rapidly in the skid-

steer case, packages such as hector_slam provide highly accurate location tracking in

unknown environments for short periods. Leveraging hector_slam’s accurate laser

scan matching methods into an improved version of amcl could lead to sufficient location

tracking for the VaultBot despite odometry modeling errors, and could be combined with

the methods presented in this work for even better results.

6.3. CONCLUDING REMARKS

The non-linear nature of the slip and friction events inherent to skid-steer

navigation introduces complex behaviors that can be difficult to model. In addition, the

presence of a dynamic center-of-gravity has a significant effect on these behaviors. This

work has clearly shown that the status-quo of ignoring these effects and simply utilizing

the traditional differential steering model is insufficient. While this work has not introduced

a perfect solution which covers all operational cases, it has made significant progress

towards improving the odometry model. This has the potential to not only improve

autonomous navigation performance but also to provide better interaction with a

teleoperator by providing consistent behavior regardless of arm configuration and CG

location.

73

Appendix A: MATLAB Numerical Solver

params.mu_x = 0.9; params.mu_y = 0.9; %Liu et al. values params.K = 13.333; params.f_r = 0.0263; %Liu et al. values params.I = 1/12*118.8437*(0.43^3+0.27^2); params.m = 118.8437; params.r = 0.328/2;

params.d_m = 0.56; params.W_b = 0.52;% VB rough approx. params.g = 9.81; %constant

inputs.F_ext_x = 0; inputs.F_ext_y = 0; inputs.F_ext_z = 0; % external forces (on EEF)

inputs.pe_x = 0; inputs.pe_y = 0; inputs.pe_z = 0; % EEF positions

inputs.x_ddot_M_B = 0; inputs.y_ddot_M_B = 0; % base acceleration

inputs.x_ddot_G_M = 0; inputs.y_ddot_G_M = 0; % COM acceleration

inputs.x_dot_M_B = 0; inputs.y_dot_M_B = 0; %inputs - base velocity

inputs.x_dot_G_M = 0; inputs.y_dot_G_M = 0; %inputs - COM velocity

inputs.x_G_M = 0; inputs.y_G_M = 0; %inputs - COM position

inputs.z_ddot_G_B = 0; %input - COM Z acceleration

inputs.z_G_B = 0.35; %input - COM Z position (VB rough approx.)

inputs.theta_ddot_M = 0; %input - base rot. acceleration

inputs.theta_dot_M = 0; %input - base rot. velocity

function F = Thesis_fsolve(x,params,inputs)

N_fl = x(1);

N_fr = x(2);

N_bl = x(3);

N_br = x(4);

q_dot_l = x(5);

q_dot_r = x(6);

...

parameter/input variable re-assignments

...

%Slip velocities

s_dot_lx = x_dot_M_B - d_m*theta_dot_M/2 - r*q_dot_l;

s_dot_rx = x_dot_M_B + d_m*theta_dot_M/2 - r*q_dot_r;

s_dot_fy = y_dot_M_B + W_b/2*theta_dot_M;

s_dot_by = y_dot_M_B - W_b/2*theta_dot_M;

%Tire friction forces - x

F_x_fl = -mu_x*N_fl*(1-exp(-

K*abs(s_dot_lx)/(1/2*(abs(s_dot_lx+r*q_dot_l)+abs(r*q_dot_l)+abs(abs(s_dot_lx+r*q_dot

_l)-abs(r*q_dot_l))))))*s_dot_lx/sqrt(s_dot_lx^2+s_dot_fy^2);

F_x_fr = -mu_x*N_fr*(1-exp(-

K*abs(s_dot_rx)/(1/2*(abs(s_dot_rx+r*q_dot_r)+abs(r*q_dot_r)+abs(abs(s_dot_rx+r*q_dot

_r)-abs(r*q_dot_r))))))*s_dot_rx/sqrt(s_dot_rx^2+s_dot_fy^2);

F_x_bl = -mu_x*N_bl*(1-exp(-

K*abs(s_dot_lx)/(1/2*(abs(s_dot_lx+r*q_dot_l)+abs(r*q_dot_l)+abs(abs(s_dot_lx+r*q_dot

_l)-abs(r*q_dot_l))))))*s_dot_lx/sqrt(s_dot_lx^2+s_dot_by^2);

F_x_br = -mu_x*N_br*(1-exp(-

K*abs(s_dot_rx)/(1/2*(abs(s_dot_rx+r*q_dot_r)+abs(r*q_dot_r)+abs(abs(s_dot_rx+r*q_dot

_r)-abs(r*q_dot_r))))))*s_dot_rx/sqrt(s_dot_rx^2+s_dot_by^2);

%Tire friction forces - y

F_y_fl = -mu_y*N_fl*(1-exp(-K))*s_dot_fy/sqrt(s_dot_lx^2+s_dot_fy^2);

F_y_fr = -mu_y*N_fr*(1-exp(-K))*s_dot_fy/sqrt(s_dot_rx^2+s_dot_fy^2);

F_y_bl = -mu_y*N_bl*(1-exp(-K))*s_dot_by/sqrt(s_dot_lx^2+s_dot_by^2);

74

F_y_br = -mu_y*N_br*(1-exp(-K))*s_dot_by/sqrt(s_dot_rx^2+s_dot_by^2);

%Rolling resistance

R_fl = f_r*N_fl;

R_fr = f_r*N_fr;

R_bl = f_r*N_bl;

R_br = f_r*N_br;

%CG accelerations

x_ddot_G_B = x_ddot_M_B + x_ddot_G_M - y_G_M*theta_ddot_M-2*y_dot_G_M*theta_dot_M-

x_G_M*theta_dot_M^2;

y_ddot_G_B = y_ddot_M_B + y_ddot_G_M - x_G_M*theta_ddot_M-2*x_dot_G_M*theta_dot_M-

y_G_M*theta_dot_M^2;

% 6 Equations, 6 Unknowns (N_fl,N_fr,N_bl,N_br,q_dot_l,q_dot_r)

F(1) = N_fl + N_fr + N_bl + N_br - m*(g + z_ddot_G_B) + F_ext_z;

F(2) = m*(g + z_ddot_G_B)*(d_m/2 - y_G_M) - pe_z*F_ext_y-F_ext_z*(d_m/2-

pe_y)+m*z_G_B*y_ddot_G_B - d_m*(N_fr + N_br);

F(3) = m*(W_b/2 - x_G_M)*(g + z_ddot_G_B)+m*z_G_B*(x_ddot_G_B) - pe_z*F_ext_x -

F_ext_z*(W_b/2 - pe_x) - W_b*(N_br+N_bl);

F(4) = F_x_fl+F_x_fr+F_x_bl+F_x_br - m*(x_ddot_G_B) - f_r*(m*(g+z_ddot_G_B)-F_ext_z) +

F_ext_x;

F(5) = F_y_fl+F_y_fr+F_y_bl+F_y_br + m*y_ddot_G_B - F_ext_y;

F(6) = (F_y_fl+F_y_fr)*(W_b/2 - x_G_M) - (F_y_bl+F_y_br)*(W_b/2 + x_G_M) + (F_x_fr+F_x_br-

R_fr-R_br)*(d_m/2 + y_G_M)-(F_x_fl+F_x_bl-R_bl-R_fl)*(d_m/2-y_G_M) + F_ext_y*(pe_x -

x_G_M) - F_ext_x*(pe_y - y_G_M) - I*theta_ddot_M;

inputs_gen

params_gen

inputs.x_dot_M_B = 0.3;

inputs.theta_dot_M = 0.1;

fun = @(x) Thesis_fsolve(x,params,inputs);

N_guess = params.m*params.g/4;

q_l_guess = (2*inputs.x_dot_M_B-params.r*inputs.theta_dot_M)/(2*params.r);

q_r_guess = (2*inputs.x_dot_M_B+params.r*inputs.theta_dot_M)/(2*params.r);

x0 = [N_guess,N_guess,N_guess,N_guess,q_l_guess,q_r_guess]

tic

fsolve(fun,x0)

toc

75

Appendix B: Result Trajectories

Figure B-1: Controller Odometry in Arc #1 Back Left Configuration

Figure B-2: Controller Odometry in Arc #1 Back Right Configuration

Figure B-3: Controller Odometry in Arc #1 Front Left Configuration

76

Figure B-4: Controller Odometry in Arc #1 Front Right Configuration

Figure B-5: Controller Odometry in Arc #1 Ready Configuration

Figure B-6: Controller Odometry in Arc #1 Ready Back Configuration

77

Figure B-7: Controller Odometry in Arc #1 Stow Back Configuration



78




79



80



81



82



83



84




85




86

Figure B-29: Controller Odometry in Rotate Back Left Configuration

Figure B-30: Controller Odometry in Rotate Back Right Configuration

87

Figure B-31: Controller Odometry in Rotate Front Left Configuration

Figure B-32: Controller Odometry in Rotate Front Right Configuration

88

Figure B-33: Controller Odometry in Rotate Ready Configuration

Figure B-34: Controller Odometry in Rotate Ready Back Configuration

89

Figure B-35: Controller Odometry in Rotate Stow Back Configuration

Figure B-36: Controller Odometry in S-curve Back Left Configuration

90

Figure B-37: Controller Odometry in S-curve Back Right Configuration

Figure B-38: Controller Odometry in S-curve Front Left Configuration

91

Figure B-39: Controller Odometry in S-curve Front Right Configuration

Figure B-40: Controller Odometry in S-curve Ready Configuration

92

Figure B-41: Controller Odometry in S-curve Ready Back Configuration

Figure B-42: Controller Odometry in S-curve Stow Back Configuration

93

References

[1] K. Nagatani, S. Kiribayashi, Y. Okada, K. Otake, K. Yoshida, S. Tadokoro, T.

Nishimura, T. Yoshida, E. Koyanagi, M. Fukushima, and S. Kawatsuma,

“Emergency Response to the Nuclear Accident at the Fukushima Daiichi Nuclear

Power Plants using Mobile Rescue Robots,” J. F. Robot., vol. 30, no. 1, pp. 44–63,

2013.

[2] J. Franco and T. Reynolds, “Carlsbad Town Hall Meeting, April 17, 2014,” US

Department of Energy; Waste Isolation Pilot Plant, 2014.

[3] R. Bogue, “Robots in the nuclear industry: a review of technologies and

applications,” Ind. Robot An Int. J., vol. 38, no. 2, pp. 113–118, Mar. 2011.

[4] A. Griffiths, A. Dikarev, P. R. Green, B. Lennox, X. Poteau, and S. Watson,

“AVEXIS—Aqua Vehicle Explorer for In-Situ Sensing,” IEEE Robot. Autom.

Lett., vol. 1, no. 1, 2016.

[5] K. Nagatani, S. Kiribayashi, Y. Okada, S. Tadokoro, T. Nishimura, T. Yoshida, E.

Koyanagi, and Y. Hada, “Redesign of rescue mobile robot Quince,” in Safety,

Security, and Rescue Robotics (SSRR), 2011 IEEE International Symposium on,

2011, pp. 13–18.

[6] H. Li, B. Li, and W. Xu, “Development of a remote-controlled mobile robot with

binocular vision for environment monitoring,” in 2015 IEEE International

Conference on Information and Automation, 2015, pp. 737–742.

[7] Y. Huang, W. Wang, and D. Wu, “Development and Optimum Design of a Mobile

Manipulator for CBRN Sampling,” in Proceedings of the 11th World Congress on

Intelliegent Control and Automation, 2014, pp. 525–530.

[8] P. Besset, “Inverse kinematics for a redundant hydraulic robotic manipulator used

for nuclear decommissioning,” in 2014 UKACC International Conference on

Control, 2013, no. September.

[9] S. Notheis, P. Kern, M. Mende, B. Hein, H. Wörn, and S. Gentes, “Towards an

Autonomous Manipulator System for Decontamination and Release

Measurement,” pp. 263–268, 2012.

[10] T. Wang, Y. Wu, J. Liang, C. Han, J. Chen, and Q. Zhao, “Analysis and

experimental kinematics of a skid-steering wheeled robot based on a laser scanner

sensor.,” Sensors (Basel)., vol. 15, no. 5, pp. 9681–702, 2015.

[11] M. Quigley, K. Conley, B. Gerkey, J. FAust, T. Foote, J. Leibs, E. Berger, R.

Wheeler, and A. Mg, “ROS: an open-source Robot Operating System,” Icra, vol.

3, no. Figure 1, p. 5, 2009.

[12] B. Gerkey, “AMCL.” [Online]. Available: http://wiki.ros.org/amcl. [Accessed: 13-

94

Nov-2016].

[13] E. Marder-Eppstein, “navigation.” [Online]. Available:

http://wiki.ros.org/navigation. [Accessed: 13-Nov-2016].

[14] B. Ebersole and M. Pryor, “Intelligent navigation of a skid steer dual-arm

manipulator with dynamic center of gravity,” in D&RS 2016 (Decommissioning

and Remote Systems), 2016, pp. 179–184.

[15] R. C. Goertz, “Master-slave Manipulator,” Argonne National Laboratory, 1949.

[16] T. Moore, “Robots for nuclear power plants,” pp. 31–38, 1985.

[17] L. Briones, P. Bustamante, and M. a. Serna, “Wall-climbing robot for inspection in

nuclear power plants,” in Proceedings of the 1994 IEEE International Conference

on Robotics and Automation, 1994, pp. 1409–1414.

[18] N. Ishikawa and K. Suzuki, “Development of a human and robot collaborative

system for inspecting patrol of nuclear power plants,” in Robot and Human

Communication, 1997. RO-MAN ’97. Proceedings., 6th IEEE International

Workshop on, 1997, pp. 118–123.

[19] Y. Iwano, K. Osuka, and H. Amano, “Proposal of a rescue robot system in nuclear-

power plants-rescue activity via small vehicle robots,” in Proceedings - 2004 IEEE

International Conference on Robotics and Biomimetics, IEEE ROBIO 2004, 2004,

pp. 227–232.

[20] C. Ducros, G. Hauser, N. Mahjoubi, P. Girones, L. Boisset, A. Sorin, E. Jonquet, J.

M. Falciola, and A. Benhamou, “RICA: A Tracked Robot for Sampling and

Radiological Characterization in the Nuclear Field,” J. F. Robot., May 2016.

[21] G. Jiang, R. Voyles, K. Sebesta, and H. Greiner, “Mock-up of the exhaust shaft

inspection by dexterous hexrotor at the DOE WIPP site,” in 2015 IEEE

International Symposium on Safety, Security, and Rescue Robotics (SSRR), 2015,

pp. 1–2.

[22] D. Kanaan, S. Dogny, and T. Varet, “Robot for investigations and assessments of

nuclear areas,” in 2015 4th International Conference on Advancements in Nuclear

Instrumentation Measurement Methods and their Applications (ANIMMA), 2015,

pp. 1–4.

[23] E. Trulls, A. Corominas Murtra, J. Pérez-Ibarz, G. Ferrer, D. Vasquez, J. M.

Mirats-Tur, and A. Sanfeliu, “Autonomous navigation for mobile service robots in

urban pedestrian environments,” J. F. Robot., vol. 28, no. 3, pp. 329–354, May

2011.

[24] A. Stentz, H. Herman, A. Kelly, E. Meyhofer, G. C. Haynes, D. Stager, B. Zajac,

J. A. Bagnell, J. Brindza, C. Dellin, M. George, J. Gonzalez-Mora, S. Hyde, M.

Jones, M. Laverne, M. Likhachev, L. Lister, M. Powers, O. Ramos, J. Ray, D.

95

Rice, J. Scheifflee, R. Sidki, S. Srinivasa, K. Strabala, J.-P. Tardif, J.-S. Valois, J.

M. Vande Weghe, M. Wagner, and C. Wellington, “CHIMP, the CMU Highly

Intelligent Mobile Platform,” J. F. Robot., vol. 32, no. 2, pp. 209–228, Mar. 2015.

[25] P. Hebert, M. Bajracharya, J. Ma, N. Hudson, A. Aydemir, J. Reid, C. Bergh, J.

Borders, M. Frost, M. Hagman, J. Leichty, P. Backes, B. Kennedy, P. Karplus, B.

Satzinger, K. Byl, K. Shankar, and J. Burdick, “Mobile Manipulation and Mobility

as Manipulation-Design and Algorithms of RoboSimian,” J. F. Robot., vol. 32, no.

2, pp. 255–274, Mar. 2015.

[26] P. Ben-Tzvi, “Experimental validation and field performance metrics of a hybrid

mobile robot mechanism,” J. F. Robot., vol. 27, no. 3, p. n/a-n/a, 2010.

[27] L. He, “Tip-over Avoidance Algorithm for Modular Mobile Manipulator *,” in

First International Conference on Innovative Engineering Systems, 2012, pp. 115–

120.

[28] S. Ide, T. Takubo, K. Ohara, Y. Mae, and T. Arai, “Real-time trajectory planning

for mobile manipulator using model predictive control with constraints,” in 2011

8th International Conference on Ubiquitous Robots and Ambient Intelligence

(URAI), 2011, pp. 244–249.

[29] Y. Liu and G. Liu, “Modeling of tracked mobile manipulators with consideration

of track-terrain and vehicle-manipulator interactions,” Rob. Auton. Syst., vol. 57,

no. 11, pp. 1065–1074, 2009.

[30] L. Caracciolo, A. de Luca, and S. Iannitti, “Trajectory tracking control of a four-

wheel differentially driven mobile robot,” in Proceedings 1999 IEEE International

Conference on Robotics and Automation (Cat. No.99CH36288C), 1999, vol. 4, no.

May, pp. 2632–2638.

[31] K. Kozlowski and D. Pazderski, “Modeling and control of a 4-wheel skid-steering

mobile robot,” Int. J. Appl. Math. Comput. Sci., vol. 14, no. 4, pp. 477–496, 2004.

[32] J. Pentzer, S. Brennan, and K. Reichard, “Model-based Prediction of Skid-steer

Robot Kinematics Using Online Estimation of Track Instantaneous Centers of

Rotation,” J. F. Robot., vol. 31, no. 3, pp. 455–476, May 2014.

[33] A. Mandow, J. L. Martínez, J. Morales, J. L. Blanco, A. García-Cerezo, and J.

González, “Experimental kinematics for wheeled skid-steer mobile robots,” in

IEEE International Conference on Intelligent Robots and Systems, 2007, pp.

1222–1227.

[34] “Motion Capture Systems | VICON.” [Online]. Available:

https://www.vicon.com/. [Accessed: 09-Nov-2016].

[35] “Fit Data with a Neural Network.” [Online]. Available:

http://www.mathworks.com/help/nnet/gs/fit-data-with-a-neural-network.html.

96

[Accessed: 09-Nov-2016].

[36] S. Kohlbrecher, O. Von Stryk, J. Meyer, and U. Klingauf, “A Flexible and

Scalable SLAM System with Full 3D Motion Estimation,” IEEE Int. Symp. Safety,

Secur. Rescue Robot., 2011.

[37] P. Corke, “Denavit-Hartenberg notation for common robots,” 2014. [Online].

Available: http://petercorke.com/doc/rtb_dh.pdf. [Accessed: 09-Nov-2016].

[38] “Actual center of mass for robot.” [Online]. Available: http://www.universal-

robots.com/how-tos-and-faqs/faq/ur-faq/actual-center-of-mass-for-robot-17264/.

[Accessed: 09-Nov-2016].

[39] A. C. Cameron, “Excel 2007: Multiple Regression,” 2009. [Online]. Available:

http://cameron.econ.ucdavis.edu/excel/ex61multipleregression.html. [Accessed:

09-Nov-2016].

Copyright by Benjamin Jarrett Ebersole 2016

Documents

Transcript of Copyright by Benjamin Jarrett Ebersole 2016