IMPLEMENTATION AND BENCHMARKING OF A WHEGS ROBOT IN THE

USARSIM ENVIRONMENT

by

BRIAN KYLE TAYLOR

Submitted in Partial Fulfillment of the Requirements

For the Degree of Master of Science

Thesis Advisor: Dr. Roger D. Quinn

Department of Mechanical and Aerospace Engineering

CASE WESTERN RESERVE UNIVERSITY

January, 2009

CASE WESTERN RESERVE UNIVERSITY

SCHOOL OF GRADUATE STUDIES

We hereby approve the thesis/dissertation of

______

candidate for the ______degree *.

(signed)______(chair of the committee)

______

______

______

______

______

(date) ______

*We also certify that written approval has been obtained for any proprietary material contained therein.

To

Dr. Dolores Yvonne Straker (mom)

Dr. Steven Lloyd Taylor (dad) and all of the fallen angels who have inspired and supported me. You will never be

forgotten and your sacrifices will not be in vain. Table of Contents

Table of Contents...... 1

List of Tables ...... 4

List of Figures...... 5

List of Figures...... 5

Acknowledgements...... 7

Acknowledgements...... 7

Abstract...... 8

Chapter 1 – Introduction and Motivation...... 9

1.1.1 – Work Involving NASTRAN 4D ...... 11

1.1.2 – Work Involving ADAMS ...... 12

1.1.3 – Work Involving Working Model 2D ...... 14

1.1.4 – Work Involving DynaMechs...... 15

1.2 – Background on USARSim...... 15

1.3 – Background on Whegs...... 19

1.4 – Motivation for Creating a Whegs Robot Model in USARSim...... 23

Chapter 2 – Methodology: Creating and Validating the Robot ...... 27

2.1 – Developing the Whegs Robot Model...... 29

2.2 – Validation Philosophy...... 33

2.3 – Qualitative Testing and Initial Benchmarking...... 36

2.4 – Quantitative Testing...... 40

2.4.1 – Substrate Friction Testing...... 41

2.4.2 – Body Rotations...... 46

1 2.4.3 – Frequency Analysis...... 53

2.4.4 – Wheel-Leg Drive Speeds ...... 54

2.4.5 – General Data Acquisition...... 55

Chapter 3 – Results ...... 56

3.1 – Making the Robot and Qualitative Testing...... 56

3.1.1 – Dimensions Used In the Simulation ...... 56

3.1.2 – Functionality for Maintaining Proper Wheel Leg Phasing...... 57

3.1.3 – Wheel-Legs Behaving as KActors vs. KTires ...... 58

3.1.4 – Effects of Individual Karma Parameters...... 60

3.1.5 – Qualitative Karma Parameter Search...... 65

3.1.6 – Performance Results ...... 67

3.2 – Quantitative Testing...... 67

3.2.1 – Substrate Friction Testing Results ...... 67

3.2.2 – Results from the Real Whegs Robot...... 68

3.2.3 – Results from the Simulated Robot (USARSim) ...... 70

Chapter 4 – Conclusions, Discussion, and Future Work ...... 74

4.1 – Conclusions and Discussion ...... 74

4.2 – Future Work...... 77

4.2.1 – Whegs Specific Items ...... 77

4.2.2 – USARSim and Other Applications ...... 80

Appendix I – Converting Velocity from World to Vehicle Coordinates...... 84

Appendix II – Dynamics of a General Inclined Plane ...... 86

Appendix III – Substrate Karma Parameters ...... 88

2 Appendix IV – Information on the High Speed Video Setup...... 89

Appendix V – Karma Parameter Values After Qualitative Benchmarking...... 90

References...... 96

3 List of Tables

Table 1. Initial and final dimensions used in the simulation...... 56

Table 2. Karma parameter values before and after the qualitative study...... 65

Table 3. Karma Actor substrate properties...... 68

Table 4. Initial and final Karma Parameters after the quantitative study...... 72

4 List of Figures

Fig. 1. Illustration of the realism that is possible in USARSim...... 17

Fig. 2. Illustration of a standardized virtual test arena (Yellow Arena) ...... 18

Fig. 3. Illustration of a standard wheel-leg...... 20

Fig 4. Wheel-legs are able to obtain footholds on objects taller than their own radius... 20

Fig. 5. Passive torsional compliance aids the robot in climbing...... 21

Fig. 6. Illustration of how a body joint can aid a robot in climbing ...... 22

Fig. 7. Illustration of a Mini-Whegs™ Robot and its size compared to a cockroach...... 23

Fig. 8. USARSim vehicle class hierarchy...... 27

Fig. 9. Wheel-Leg appendage created in UnrealEd...... 29

Fig. 10. Implementation of passive torsional compliance into USARSim...... 31

Fig. 11. Illustration of th edifferences between KTire and KActor wheel-leg behavior . 33

Fig. 12. Illustration of how robots in USARSim are currently validated...... 34

Fig. 13. Pictures of the obstacle map that was created for testing the virtual robot...... 37

Fig. 14. Illustration of head-on and oblique approaches...... 38

Fig. 15. Illustration of the real inclined plane – block setup...... 41

Fig. 16. Picture of the block and mass used in the real-world inclined plane setup...... 42

Fig. 17. Illustration of the simulated inclined plane setup...... 43

Fig. 18. Final map used in quantitative testing...... 44

Fig. 19. Illustration of UnrealEd’s TERRAIN functionality ...... 45

Fig. 20. Illustration of digitized high speed video footage...... 48

Fig. 21. Illustration of a standard 3D high speed video setup...... 49

Fig. 22. A Mini-Whegs™ robot with digitization points an calibration object...... 49

5 Fig. 23. Illustration of digitized points that are used to extract body rotations ...... 51

Fig. 24. Description of the vehicle coordinate system that is used...... 52

Fig. 25. Extra class functionality is required to maintain proper wheel-leg phasing...... 57

Fig. 26. Illustration of the inaccuracy of a KTire wheel-leg implementation...... 59

Fig. 27. Sample velocity magnitude plots in both vehicle and world coordinates ...... 61

Fig. 28. Sample plot of 3D coordinate data from the real robot ...... 68

Fig. 29. Sample plot of Roll and Pitch euler Angles from the real robot ...... 69

Fig. 30. Sample plot of initial Roll and Pitch Euler Angles from the simulated robot.... 70

Fig. 31. Sample plot of final Roll and Pitch Euler Angles from the simulated robot...... 72

Fig. 32. Sample plots of power spectra from the real and simulated robots...... 73

6 Acknowledgements

The list of people who are thanked here does not by any means name everyone

who has helped me in bringing this phase of my graduate work to completion. However,

there are some particular people I would like to recognize. I would like to thank Roger

Quinn, the Biologically Inspired Robotics Laboratory, and Case Western Reserve

University’s department of Mechanical and Aerospace Engineering for being such a

phenomenal place to work, learn, grow and play. I knew this before, but, especially after

losing my mother, with what I have seen from these people, I can honestly say that there is no other place in this world that I would want to call “my school”. I would also like to thank the Department of Homeland Security (DHS) and the Oak Ridge Institute of

Science and Education (ORISE) for funding my graduate work thus far1.

I must thank my family. Whether or not they know it, they are the source of my

strength, commitment, resolve, and drive to go after the things I want in life and to do the

best that I can in all that I do. They are what give me the strength to keep going even

when I don’t think that I have anything left to give.

Last, and yet above all, I thank the late Dr. Dolores Yvonne Straker (mom) and

the late Dr. Steven Lloyd Taylor (dad) for all that that they have given me. They are why

I am here. They are why I am who I am. They are why I do what I do. Without them, I

would be nothing.

1 This research was performed under an appointment to the U.S. Department of Homeland Security (DHS) Scholarship and Fellowship Program, administered by the Oak Ridge Institute for Science and Education (ORISE) through an agreement between the U.S. Department of Energy (DOE) and DHS. ORISE is managed by Oak Ridge Associated Universities (ORAU under DOE contract number DE-AC05- 06OR23100. Opinions expressed here do not necessarily reflect those of DHS, DOE, or ORAU/ORISE.

7 Implementation and Benchmarking of a Whegs Robot in the USARSim Environment

Abstract

by

BRIAN KYLE TAYLOR

Simulating robots in a virtual domain has multiple benefits, including serving as a

training tool for end-users and a tool for robot development/testing. USARSim (Unified

System for Automation and Robot Simulation) is a tool that can accomplish these goals.

It is based on the Unreal Tournament 2004 gaming engine, which approximates the

physics of how robots interact with their environments. Whegs™ robots (mobile ground

vehicles that derive robust locomotion from abstracted biological principles) can benefit

from simulation in USARSim. This thesis describes a Whegs™ robot model that was

constructed and benchmarked in USARSim. The simulation was given the same

behavioral characteristics as real Whegs™ vehicles and then validated. Qualitative tests

were performed for basic walking and climbing to understand the vehicle’s behavior.

Quantitative tests were performed for basic walking to: compare the simulated robot’s rotational body movements to those of the real robot, and to improve the simulation’s performance.

8 Chapter 1 – Introduction and Motivation

1.1 – Background on Dynamic Simulation

Dynamic simulations have been used extensively to study and solve a wide variety of engineering problems [1-11]. Software that is used ranges from open source packages (such as USARSim and DynaMechs) to commercially available software (such as Visual Nastran4D). Simulation allows systems to be studied without needing to directly test or experiment on the real-world system in question. This kind of testing is useful in design work to predict how a system that does not yet exist or is in development may perform under different conditions so that the design may be modified and refined.

This also allows for testing systems in situations that may be impractical, infeasible, or involve too much risk for direct real-world testing.

An important point to keep in mind is that all simulations are only modeled representations of the real world, and as such, all simulations are subject to behavioral errors and non-physical results. Therefore, when using any simulation software, it is important to consider whether or not the results make physical sense and can be justified based on fundamental principles (e.g., if a rigid body exhibits odd behavior in a simulation, then that behavior must be defensible based on a free-body diagram of the rigid body) [12, 13]. It is also important to benchmark simulations either directly against real-world cases, or against problems with known solutions to make sure that the simulation is solving the problem correctly and to an acceptable level of accuracy and precision. The level of accuracy and precision that is needed depends on the context of the particular problem that is being solved. One study that has performed a simulation of a real-world system and then validated that simulation experimentally is presented in [9].

9 Also, the study presented in [10], where a CFD simulation is validated based on real- world results, illustrates the need to benchmark simulations against real-world or known solutions.

To provide some background on dynamic simulations (particularly USARSim), work that has been done with various simulation software is first presented in sections

1.1.1 – 1.1.4. Specifically, the packages that are outlined in this work are:

• Visual NASTRAN 4D (Commercial Software) [14]

• ADAMS (Commercial Software) [14]

• Working Model 2D (Commercial Software) [15]

• DynaMechs in conjunction with RobotBuilder (Open Source – Available at

SourceForge) [16, 17]

• USARSim (Open Source – Available at SourceForge) [18]

It is important to note that there are also other commercial, open source and custom packages that are available, such as software from Yobotics! [19]. However, this section is only intended to give a brief summary of some of the solutions that are available and what they have been used for. It is not a comprehensive review of all simulation packages.

Section 1.2 provides a separate and more detailed background on USARSim.

Section 1.3 provides background on Whegs™ robots. Section 1.4 motivates the need for implementing a Whegs™ robot into USARSim. It also motivates the rationale behind using USARSim as the simulation package for this study. Although USARSim is the package that is used for this work, as will be explained, the methods that are employed here (particularly for benchmarking) can be ported to any simulation package.

10 1.1.1 – Work Involving NASTRAN 4D

Visual NASTRAN4D is a commercially available software package that is

developed by MSC Software [14]. It is used to perform either finite element work or

dynamic simulations. As is the case with many simulation packages, it is capable of

importing 3D solid models from CAD software such as Pro-Engineer or Solidworks. A

variety of work has been done using this software. To provide one example, Hoeg et al.

used this package to simulate a wind driven Mars Tumbleweed Rover [1, 2, 11]. For

Mars exploration, one key in-situ (already available on site) resource that can be

harnessed is the natural wind that occurs on the planet. A rover that is able to use the

wind to power its locomotion provides a variety of advantages over conventional

exploration systems. In particular, a wind driven rover can employ a drive train that is

much smaller, less massive, and consumes less power. The overall goal of this work is to

use swarm intelligence with a number of rovers for cooperative exploration. Visual

NASTRAN4D was used to study a given rover’s performance during obstacle navigation

and path deflection (i.e. when the rover’s path is changed based on the orientation of an

obstacle that it interacts with such as an irregularly shaped rock). It was also used to

study possible mechanisms that could be used to steer and stop the rover. The dynamics

information that was obtained from this study was fed into a separate stochastic simulation that studied a group of rovers exploring the planet [1, 2] (more is said about this “separation of simulations” in section 4.2.2). The study was able to provide information on the relationship between the rover’s incoming momentum and its obstacle navigation performance. In addition, the study also revealed important trends in terms of

11 steering the rover using offset masses, and illustrated that obstacle height is the key factor

in a rover being deflected from its current path.

1.1.2 – Work Involving ADAMS

ADAMS is another commercial package that is currently marketed by MSC

Software. An example application of ADAMS was the study of an anti-lock brake

system (ABS) algorithm [3]. To provide a brief summary, the goal of the study was to

provide designers with a model that could be used to aid in deciding which particular

tires are more suitable for use with an ABS system. A quarter vehicle model with

appropriately inserted reaction forces was used to test one wheel of a vehicle. This model

was then used to analyze the performance of two distinctly different tires. Two control

algorithms were used to model the ABS control. Using ADAMS, the study was able to

provide a comparison of the two tires by providing information on Braking Force vs.

Wheel Slip Ratio. It was also able to provide relationships for: Stopping Distance vs.

Time for both tires under wet and dry road conditions, Vehicle and Wheel Speed vs.

Time, and Slip Ratio vs. Time.

Another work that used ADAMS involved developing a model to simulate and

study Sport Utility Vehicle (SUV) handling stability [4]. A full vehicle body model was

created for an SUV. ADAMS was used to study the effects of: a step input into the

steering wheel, turning radius as a function of vehicle speed and vehicle stability. In this

particular work, the vehicle’s subsystems (e.g. front suspension, rear leaf spring, torsion-

bar spring, stabilizer bar) were all modeled and assembled in CAD software and then

imported into ADAMS, where the physical dynamics modeling and simulation was

performed. That is, in addition to performing the full simulation, ADAMS is where

12 properties such as tire models and leaf spring stiffness are set. The full vehicle was

assembled in the simulation once all of its subcomponents were successfully modeled.

A third example work that used ADAMS involved successfully developing a controller to stabilize the torso of a human walking gait model that walks along prescribed foot and joint trajectories [5]. In walking gait simulations, as time progresses, errors between expected and actual quantities (e.g. position and velocity) can begin to propagate into successive time steps. For a human walking model, after just a few step cycles, these errors lead to instabilities that cause the walking model to fall down. The stabilizing controller was developed to correct these instabilities so that longer simulations could be performed. This kind of correction allows for the simulation and study of steady state walking. One particularly important point that [5] mentions is a previous study [6] that developed a controller for the same purpose (i.e. stabilizing the body to allow for longer simulations). In the study presented in [5], the controller only uses the model’s joint torques and natural external forces that act on the model such as gravity and foot contact. However, in the study presented by [6], the controller was developed by applying external forces and moments to the head-arms-trunk segment of the simulation model. While this method may work in terms of producing the desired simulation result, it has no physiological justification (i.e. this is not what one would see in a real human) [5]. The only external forces that act on an individual in walking, and that should therefore act on a simulation model are those due to gravity, ground contact forces, and joint torques. The conclusion that should be drawn from this point is that the degree of physical relevance must be understood for any functionality that is imparted to, or behavior that is observed in a simulation. Depending on the particular application, it

13 may be acceptable or desirable to achieve a physically relevant result by using a method

that does not entirely reflect what one would see in reality. However, it must be known

that the method being used is not entirely physically relevant, since the method can have an influence on the results and how they are interpreted. Also, any particular implementation method (physical or nonphysical) must provide results that are physically

justifiable. So, even if the method itself is not reflective of reality, the physical results

that are generated must mirror what one would expect to see in the real world.

1.1.3 – Work Involving Working Model 2D

Working Model 2D is a commercial software package that performs 2

dimensional dynamics simulations. Boxerbaum et al. used this software to gain an

understanding and improve the performance of a one meter long Whegs™ robot with a

body joint [7]. One of the key parts of the work was using the simulation to “close the

loop” on an identified problem. Through testing of the real robot, a high-centering failure

of the robot in question was observed during climbing. Using the simulation package, the

hypothesis that the high centering failure was due to the center of mass being located too

far aft on the vehicle was verified. By shifting the center of mass forward, the simulation

predicted that climbing performance would improve, and that the robot would be able to

surmount taller obstacles. This hypothesis was validated on the real robot by changing its

mass distribution. This sequence of events (identifying a problem in the real-world,

using the simulation to confirm why the problem is occurring, using the simulation to

devise a solution to the problem, and then testing/validating that solution in the real

world) illustrates the utility of a simulation in terms of improving system performance.

In addition to solving the high centering problem, the simulation was used to find and

14 examine body joint [20, 21] flexion strategies for climbing stairs and for navigating a

highly unstructured environment. It is noted here that the strategies that were found were

not autonomous strategies. Rather, they required a user to observe the robot and issue

commands based on the observed performance.

1.1.4 – Work Involving DynaMechs

DynaMechs [16] is an open source package that uses an Articulated Body (AB)

algorithm to provide real-time simulations of robotic systems [22]. This package is designed to efficiently solve the equations of motion and is capable of modeling both ground and underwater vehicles. It has specific provisions in place for modeling hydrodynamic forces including the effects of drag, buoyancy, fluid acceleration and added mass. The algorithm for solving the equations of motion is implemented using object oriented design (OOD) techniques in C++. The user is able to specify a control algorithm as an input for their vehicle. RobotBuilder [17] is used to build a simulation, then run and view the simulation results that are computed in DynaMechs. Some work that has used this package includes the design of a control algorithm that seeks to stabilize pitch and roll in a trotting quadruped while simultaneously preserving its natural

dynamics based on the Spring Loaded Inverted Pendulum (SLIP) model [8].

1.2 – Background on USARSim

Unified System for Automation and Robot Simulation (USARSim) is a high fidelity simulation tool that can be used to simulate robotic systems in various environments [18, 23-25]. It was originally intended for use as a training tool for mobile robot users such as first responders. USARSim’s foundation software is Epic Games’

Unreal Tournament 2004 (UT2004) physics engine known as Unreal Engine 2.0. The

15 Karma Physics Engine [26] is utilized to approximate physics and dynamics within the game. Unreal Script, UT2004’s object oriented programming language (similar in nature to C++ and JavaScript [27]), is used to give robots functionality, and to define how a robot will interact with its environment. Unreal Editor (UnrealEd), a solid modeling graphical user interface that comes with UT2004, is used to create virtual worlds (maps).

It is also used to create 3D solid models (static meshes) that can be used to construct robots or obstacles and objects that are placed within a particular map [28-30]. More advanced parts and/or textures can be made by using software such as Maya or 3DS Max.

USARSim is used to model robotic systems as follows. A virtual robot model is built by creating static meshes to represent its individual parts. The parts are connected to each other through a configuration file that specifies the connection locations and the types of connections to be used (e.g., motors and hinges). This file also specifies other properties of the robot such as its mass, maximum motor torque, and the locations of sensors that may be mounted to it. The robot is given specific functionality through its own class and its parent classes. In addition to the virtual robot, a map is created with obstacles that must be negotiated, and objects and/or victims that must be found.

Features such as the terrain to be negotiated (such as hills and valleys) and lighting of different parts of the map can also be set (e.g., there are maps where one part of the environment is completely lit, and another part of the environment is so dark that a robot must have some kind of lighting on board). By adjusting simulation parameters called

Karma Parameters [26, 31], the performance of the virtual robot can be changed (e.g. changing the inertia tensor of a robot will affect its resistance to rotational acceleration about particular body axes). End users can select from robots and vehicles that are

16 available in a current release of USARSim [18], or design their own vehicle from scratch.

Control software such as Usar_UI [18] or MOAST [32] is used to issue basic commands, implement autonomous features, and run multiple vehicles in a given environment. With

MOAST, a user can connect a joystick or other type of input control device to the system for more realistic operation. MOAST also enables a user to implement different types of control algorithms for robots [33]. This kind of setup allows users to build and simulate a robot or group of robots relatively quickly and inexpensively from both computational and monetary standpoints as compared to rigorous physics solutions.

As Figs. 1 and 2 show, USARSim is able to produce extremely realistic results in terms of the look and feel of a robot and its surrounding environment.

Fig. 1. (Left) Comparison of a real AIBO robot (Sony) and its USARSim counterpart. (Right) The Talon™ robot finding a person in a USARSim scenario.

17

Fig. 2. Illustration of a simulated environment in USARSim. This is a virtual version of the yellow test arena (yellow refers to the level of difficulty of the arena). As can be seen, this environment has obstacles that a given vehicle must overcome, victims that the vehicle must find, and changes in lighting that necessitate the use of a given vehicle’s on- board lighting to illuminate various parts of the world [18, 34].

Other studies such as those presented in [27, 28] have shown that beyond a realistic feel and look, robots in USARSim can be tuned to have realistic and physically relevant performance as well. Because USARSim is based on a game that is designed to respond to the user’s inputs in real time, a user can control their robot and see how their model fares in different scenarios immediately rather than having a time delay from the time the simulation is started to the time the simulation is done. This enables changes and/or improvements to be made to a particular simulation relatively rapidly. USARSim currently has applications in end-user training for robots and in the RoboCup Simulation

League [24, 25]. One of the goals of USARSim is to incorporate validated versions of virtual test methods (such as step fields and other pre-constructed environments) that are

18 being developed for DHS to be used within ASTM International. This will allow dissemination of standardized virtual vehicle tests and challenges for developers and end users [30, 34].

A disadvantage of USARSim is that the Karma Physics Engine is proprietary.

This means that the exact mechanics of how the engine uses the Karma Parameters are not publicly known. While testing has been done to gain a quantitative understanding of how the Karma Parameters affect the simulation and map to real-world quantities, there are still parameters where this level of understanding has not been reached. Ultimately, this means that iterative testing and comparisons must be done for a given real robot and its virtual counterpart to determine an appropriate set of Karma Parameters that yields realistic performance of the virtual vehicle.

1.3 – Background on Whegs

Whegs™ robots are highly mobile unmanned ground vehicles that were developed in the Biologically Inspired Robotics Laboratory at Case Western Reserve

University. Their locomotion is based on abstracted biological principles observed in cockroach locomotion [35]. Unlike RHex which is a biologically inspired robot that predates Whegs™ [36], Whegs™ robots employ an appendage called a wheel-leg, which is made up of a hub with spokes equally spaced about the hub’s central axis (Fig. 3)

19

Fig. 3. Illustration of a three spoke wheel-leg.

Rotating the wheel-legs about their central axes at a constant speed allows a given

Whegs™ robot to move in the same way that a wheeled vehicle would be driven. In

addition, the spokes allow the robot to obtain discontinuous footholds on irregular terrain, similar to legs [20]. Furthermore, the spokes also allow the wheel-leg to reach footholds that are taller than the wheel-leg radius. These features allow Whegs™ robots to be propelled in a similar manner to wheeled vehicles while simultaneously enabling them to climb over and negotiate terrain that may be impassable to wheeled vehicles (Fig. 4).

Fig 4. (a) A wheel-leg is able to obtain footholds on obstacles that are taller than the wheel-leg radius. (b) A wheel is unable to reach footholds of equal height.

Cockroaches have six legs and typically walk in an alternating tripod gait. A

tripod gait means that the front and rear legs on one side move in phase with the middle

20 leg on the opposite side. Three of the legs form one tripod while the other three form a

second tripod. The two tripods move in anti-phase with each other. As a result,

contralateral pairs of legs move in anti-phase with each other (e.g. when the front left leg

is in swing, the front right leg is in stance) [37]. When the animal encounters a large

barrier, it moves its contralateral legs into phase to aid in surmounting the obstacle [21].

Similarly, Whegs™ robots typically employ six wheel-legs with contralateral pairs being

placed in anti-phase such that the vehicle walks in a nominal tripod gait. Each axle

features a compliant mechanism that allows a given robot to passively bring its wheel-leg pairs into phase. This feature aids robots in surmounting obstacles and allows them to passively adapt their gait to changing, irregular and adverse terrain (Fig. 5).

Fig. 5. Compliant mechanisms in the axles allow wheel-leg spokes to come into phase, which aids in climbing obstacles.

In general, the torsional springs in the compliant mechanisms are pretensioned in order to

preload the mechanism. This biases the mechanism to a particular direction and helps to

limit the types of disturbances that will cause a robot to alter its gait (e.g, the robot will

maintain a tripod gait while walking on flat, smooth terrain, but will alter its gait when

climbing an obstacle). Also, the range of motion of the compliant devices is typically

21 limited to 60o in order to allow contralateral wheel-leg pairs to shift from being in anti- phase to being directly in phase.

Also, cockroaches have a body flexion joint. They use the joint to pitch the front of their bodies down to avoid high centering and to allow their front legs to reach the substrate during climbing [21]. More recent Whegs™ robots have been outfitted with body flexion joints for similar reasons. In addition, the joint also allows the vehicle to pitch its body upward to get a foothold on an obstacle during a climb (Fig. 6) [20].

Fig. 6. A Whegs™ robot with a body flexion joint surmounting a step that is larger than the robot’s body height.

In addition to Whegs™ robots, a series called Mini-Whegs™ has also been developed (Fig. 7).

22

Fig. 7. Mini-Whegs™ and its relative size as compared to a Blaberus giganteus cockroach.

Mini-Whegs™ robots are intended to be smaller, more compact versions of

Whegs™ robots. They are on the order of 0.09 m long (9 cm), and have a top speed of

up to 10 bodylengths/second (0.9 m/s). To give a comparison, DAGSI Whegs™ [7] is on

the order of 0.9144 m long and 16 kg whereas Mini-Whegs™ is on the order 0.09 m long

and 0.1 kg. Because of their small size, Mini-Whegs™ robots usually only possess four

wheel-legs that move in an alternating diagonal gait (vs. six in an alternating tripod gait).

While some work has been done with implementing compliance into the axles of these

vehicles, and while one particular vehicle has been outfitted with a body joint for

climbing research [38], Mini-Whegs™ robots typically lack both torsional compliance

and body flexion joints [39].

1.4 – Motivation for Creating a Whegs Robot Model in USARSim

Several styles and types of Whegs™ robots have been constructed and tested. For example, Whegs™ I, the progenitor of all Whegs™ vehicles, had compliant axles and was able to surmount various obstacles [21]. Whegs™ II added to the functionality

23 present in Whegs™ I by incorporating the use of a body joint [20] and sensors that allow

for semi-autonomous navigation [40, 41]. Currently, there is a version of Whegs™ that

is being developed for lunar excavation [42]. A Whegs™ robot called DAGSI Whegs™

is being developed to host a suite of sensors for autonomous operation [7]. Mini-

Whegs™ has gone through several incarnations in terms of size, wheel-leg radius, and

wheel-leg type (e.g., number of spokes, type of material and splay angle for the tip of the

wheel-leg).

Despite the large amount of design, construction and testing work that has gone

into the various Whegs™ robots, there is currently no formalized method for developers to gauge a robot’s performance, predict its operational limits or test the viability of design

ideas before construction begins. This is particularly true from a behavioral standpoint.

As a result, once an initial design is completed and constructed, there can be a great deal

of redesign and re-fabrication work that must take place to improve and perfect the robot.

Also, the only current method for learning how to operate a Whegs™ robot (whether it is

semi-autonomous or purely remote controlled) is to drive a real robot through different

environments and under varying conditions. A Whegs™ simulation would allow robot

designers to test their ideas and gauge a given robot’s performance limits before

construction begins, allowing them to make design changes that will improve

performance and increase robustness. The simulation can also be used by developers to

test robots in environments that are not readily available, or potentially damaging. For

robots in development, performance enhancing changes could then be implemented based

on the performance of the simulation. In addition to design work, a Whegs™ robot

simulation would allow end users to become skilled in operating Whegs™ vehicles in

24 numerous environments without having the robot or environment(s) physically present.

This can reduce the risk of damaging the robot or the environment. If a simulated robot is incapacitated, the simulation can simply be restarted rather than having to repair or rebuild the vehicle.

There are additional benefits to creating a Whegs™ simulation. There are also benefits to using USARSim. In developing any simulation model (particularly one for

Whegs™), a benchmarking process for that model must be established to ensure that the simulation results mirror what one would see in reality. In this work, a benchmarking process is developed that can be used to examine and validate robot performance from any simulation package. If a user wanted to use a different package to perform a different type of study, even though the implementation of the robot would change, the benchmarking process would stay the same.

For this study, USARSim is the package of choice because it is widely used and accepted as a valid simulation package. For example, as stated above, it is the basis of the RoboCup Simulation League. Also, other research studies such as that presented in

[43] are using USARSim for their purposes as well. In addition to this, USARSim has many built in features and capabilities that make it relatively easy to learn to use. Also, as stated above, the control software that can be used in conjunction with USARSim allows for the potential of developing and implementing relatively sophisticated control and autonomy algorithms. As stated previously, although USARSim is used here because of these capabilities, the benchmarking methodology developed here could be transferred to any simulation package.

25 In this work, a virtual Whegs™ robot was created and given the same behavioral

characteristics as a real robot. The virtual robot’s performance and simulation parameters

were then benchmarked against the real robot. Qualitative methods were used to

establish initial estimates of acceptable performance. Once the vehicle’s qualitative

performance reached an acceptable level, quantitative measures were used to further

improve the virtual robot’s performance. The virtual design of the robot (i.e., creating the

robot and incorporating appropriate functionality) is outlined in section 2.1. The

benchmarking methodology that is used is presented in sections 2.2 – 2.4. The final

details and results of the robot’s implementation and benchmarking are given in sections

3.1 and 3.2 respectively. A discussion of the work to date and future directions that can be taken are presented in sections 4.1 and 4.2.

26 Chapter 2 – Methodology: Creating and Validating the Robot

To perform this study, a semi-generic Whegs™ robot model was first created in

USARSim by adding a “Whegs” class. This class and its parent classes were given functionality to enable the virtual robot with the same behavioral characteristics that are

found in real Whegs™ vehicles. A brief USARSim vehicle class hierarchy is shown in

Fig. 8 for illustration and reference.

KRobot

Ground Vehicle Nautical Vehicle Aerial Vehicle Legged Vehicle

Skid Steered Vehicle Ackerman Steered Vehicle

Whegs Vehicle

Fig. 8. Illustration of the class hierarchy for vehicles in USARSim. Here, Ackerman Steered vehicles are vehicles that physically turn their wheels to steer, and skid steered vehicles are vehicles that use differences in contralateral wheel speeds to steer. The KRobot class’s functionality was slightly modified to make the Whegs™ class function properly.

After the virtual robot was enabled with the necessary behaviors, it was run through several tests to gain an understanding of how individual Karma Parameters affected its performance. Once the effects of these parameters were known, the virtual and real robots were placed in qualitative test scenarios with the same conditions. The results of these tests were compared and used to make changes to the virtual robot’s

27 Karma Parameters to establish an initial estimate of acceptable virtual performance.

Once a reasonable level of qualitative virtual performance was established, quantitative testing was performed on both the real and simulated robots to gain a better understanding of how well the simulation matched the performance of the real robot.

Qualitative tests involved running the virtual and real robots over basic obstacles and in open spaces. Quantitative tests involved using high speed video to test the real robot on a substrate with experimentally determined properties.

For the purposes of this study, the virtual vehicle was modeled after a Mini-

Whegs™ robot with torsional compliance. This was done in an effort to lay the foundation for creating any given Whegs™ vehicle while still maintaining a degree of simplicity during modeling and testing. As stated above, Mini-Whegs™ robots typically lack a body flexion joint and only use four wheel-legs. These features make Mini-

Whegs™ robots easier to simulate because there are fewer features to control and less wheel-legs to monitor during testing. Torsional compliance, while not present on all

Mini-Whegs™ vehicles, was not a feature that was readily available for application to a motorized axle in USARSim. Because torsional compliance is found on so many of the

Whegs™ vehicles, it was felt that successfully modeling and implementing it would aid in laying the fundamental groundwork necessary for building more specific and accurate

Mini-Whegs™ and Whegs™ robot models. For the purposes of the quantitative study, since the real robot in question does not have torsional compliance, the simulation’s torsional stiffness was set so that it did not have an impact on the operation and performance of the virtual robot.

28 In this chapter, section 2.1 outlines how the robot was modeled in the USARSim

environment. Sections 2.2, 2.3 and 2.4 outline the philosophy behind benchmarking

robots in USARSim, the qualitative test methods that were employed and the quantitative

test methods that were employed.

2.1 – Developing the Whegs Robot Model

Modeling a Whegs™ vehicle in USARSim can be broken down into two main steps: creating the appropriate static meshes, and writing and modifying classes to give

the virtual vehicle the same types of behavioral characteristics as the real vehicle. The

static meshes for this study were created using UnrealEd. For the purposes of simplicity,

the chassis of the robot was modeled as a rectangular block rather than modeling each

individual component (e.g. side rails, motor, axles, servos). The wheel-legs were modeled as cylinders (the hub of the wheel-leg) with three rectangular blocks (the spokes of the wheel-leg) attached to them and placed 120o apart (Fig. 9).

Fig. 9. Wheel-Leg appendage created in UnrealEd.

29 Two separate wheel-leg meshes were made. One resembled a “Y” shape (Fig. 9) while the other was an inverted “Y”. The two meshes were used as contralateral leg pairs to achieve proper wheel-leg phasing.

Incorporating the appropriate behavioral characteristics into the virtual robot involved adding new functionality to USARSim. As mentioned above, there were no native USARSim features that allowed for passive torsional compliance as necessary on a motorized axle. To solve this problem, a new class called “KDSpringy” was created.

This class, combined with parent class changes, tells USARSim to make a hinge joint

(KHinge) whose hinge type is set to a spring (KHingeType = Springy). Physically, this is like connecting two objects together with a torsional spring that is able to have stiffness and damping about a particular axis. The spring attempts to maintain an input angle

(KDesiredAngle) between two objects placed in an UT2004 map (objects placed in an

UT2004 map are also known as Actors). On a vehicle in USARSim, this corresponds to maintaining a desired angle between the current part and its parent. Once the KDSpringy class was created and the appropriate parent classes were modified, torsional compliance was implemented in the following way.

30 KDSpringy KCarWheelJoint

Chassis

Wheel-Leg Joint Spacer Plate

Fig. 10. Illustration of how passive torsional compliance is implemented.

A static mesh that is used as a spacer plate was created. As can be seen in Fig. 10, the chassis was connected to the spacer plate via a KCarWheelJoint. Briefly, a

KCarWheelJoint is a joint that has a spin axis that is driven by a motor, and a steering axis that is driven by a controlled motor that attempts to achieve a specified orientation

(similar to a servo). KCarWheelJoints can also be set to use linear suspension as well

(similar to the way an actual car wheel works). The spacer plate was connected to the wheel-leg via KDSpringy. This setup effectively made the spacer plate the actual

“wheel” that propelled the vehicle. However, because the wheel-leg’s parent is the spacer plate, the two parts rotate together. Differences in their rotational speeds come from the reaction torques and forces that are experienced by the wheel-leg from the terrain, and from the parameter used to set the stiffness of KDSpringy. A large stiffness allows the spring to withstand large reaction torques before deflecting, thus allowing the wheel-leg and spacer plate to move at more closely matching speeds (this corresponds to the wheel-leg functioning like a normal wheel, or no torsional compliance). A lower

31 stiffness means that the spring is easier to displace and must be deflected to the point

where it is able to exert a large enough torque to spin the wheel-leg. This enables the spacer plate to wind up the spring and build torque when a particular wheel-leg is unable to move, which allows the contralateral wheel-leg to come into phase. This is precisely how Whegs™ robots behave in reality when surmounting obstacles. It should be noted that, for the purposes of simplicity, pretensioning of the springs is not used in implementing simulated torsional compliance.

A disadvantage to this implementation of passive torsional compliance is that it disables the user from making the wheel-leg a tire. UT2004 appears to only use tire properties for a tire (a KTire in UT2004) that is connected to a KCarWheelJoint. KTire

properties allow the user to control the following properties of the tire: Rolling Friction,

Lateral Friction, Rolling Slip, Lateral Slip, Minimum Slip, Slip Rate, Tire Softness, Tire

Restitution, and Tire Adhesion. Even though the wheel-legs are defined as KTires, since they are connected via KDSpringy and not a KCarWheelJoint, it appears that they only have what are known as KActor properties. KActor properties allow the user to control the following parameters: KFriction and KRestitution. An illustration of the differences that arise from the KActor implementation vs. the KTire implementation is shown in Fig.

11 below.

32

Fig. 11. Illustration of the differences between a KTire vs. KActor implementation of the wheel-legs. The red lines in both pictures represent contact and/or penetration of one object into another. The yellow lines in (a) indicate that the object that is contacting the ground is a KTire and has properties such as rolling and lateral friction. As can be seen, (b) only has red lines at the contact points between the wheel-legs and the substrate.

KTire is the more realistic choice because more control is allowed over how the

tire will interact with the environment. This problem can be rectified by altering the wheel-leg static mesh to contain a hub and individual wheel-leg spokes that are added to

the hub as tires. However, this solution requires a larger number of parts and more class

functionality to make the robot function properly. Also, this approach gave adverse

preliminarily results, which are discussed in Section 3.1.3. This knowledge, combined with the fact that real Mini-Whegs™ robots do not use formal tires led to the validation

being performed with the wheel-legs as KActors. It was felt that this approach would

provide a reasonable first approximation of the appropriate set of Karma Parameters that

would yield realistic virtual performance while narrowing the parameter search space at

the same time.

2.2 – Validation Philosophy

33 The general process of how robots in USARSim are currently validated is given

in Fig. 12.

Virtual Robot

Karma Parameters Karma Physics Engine Virtual Performance

Real Robot Performance Visual Observation

Data Comparison

Real Data Simulated Data

Fig. 12. Illustration of how robots in USARSim are currently validated.

As stated above, the Karma Physics Engine is proprietary, which means that the exact way in which the engine uses the Karma Parameters to affect the simulation cannot be directly obtained. In addition, the engine uses its own internal unit system to perform computations (e.g. lengths are in Unreal Units or Karma Units depending on the context).

While the mapping between UT2004 and reality has been obtained for some parameters

(e.g. length and time), other parameters such as force and torque are still under investigation. Also, while many of the Karma Parameters are similar in concept and

34 effect to known quantities, they do not necessarily have a direct mapping or analogue to

real world properties (e.g., increasing KFriction increases the friction of a single object, whereas increasing the coefficient of friction increases the friction between two objects).

Due to the proprietary “black box” nature of the engine, to perform a validation for a robot in USARSim, a virtual robot is first run through the engine with an initial set of

Karma Parameters, as illustrated in Fig. 12. This yields the robot’s virtual performance, which is then compared with real robot performance through the use of video data and/or and any other relevant performance metrics for the robot in question (e.g. one would expect that the performance metrics for a Mini-Whegs™ robot would be different from that of a Humvee or an aerial vehicle). The information learned from the comparison is used to modify the Karma Parameters in a physically appropriate way. After parameter modification, the virtual robot is run through the engine again for a second comparison with the real robot. This cycle is repeated until an acceptable level of performance is reached for the virtual robot. In terms of understanding the robot’s qualitative behavior, acceptable performance is determined by visually observing whether or not the simulated robot is able to perform the same tasks as the real robot (e.g. climbing over obstacles of

equal height). To understand the robot’s quantitative behavior, acceptable performance is

determined by observing whether or not the virtual robot’s Pitch and Roll angle ranges

and frequencies match those of the real robot. Simulated data that are within 5% to 10%

of the real robot’s values would be expected to yield appropriate behavior of the virtual

robot.

Before conducting any testing in USARSim, it must be recognized that any test

that is to be performed in reality must be able to be replicated in the simulation. This

35 includes both the test that is to be performed and the data that can be collected from it.

This is important to note because, as previously stated, there is not currently a complete

mapping between all of the simulation parameters and real world quantities. For a

complete mapping, one would need to benchmark the physics engine itself against basic

canonical problems in dynamics (discussed further in section 4.2.2). This kind of study is

beyond the scope of this work. Kinematic parameters (position and orientation) and time

can be definitively measured in both the real and simulated worlds. As a result, for the

purposes of this study, the virtual robot is benchmarked using quantities that can be

derived from these parameters, such as velocities and Euler Angles.

2.3 – Qualitative Testing and Initial Benchmarking

After the virtual robot model was developed and given the necessary functionality

as described in Section 2.1 above, two maps were created to test the vehicle’s

performance. The first map was a large empty room to test the vehicle in walking and

running. The room was made to be much larger than the vehicle (~12 m x ~12 m) so that the robot could be run for a long period of time at any given drive speed. This ensured that the data that was collected contained the steady state performance of the vehicle under any set of operating conditions. The second map included basic obstacles such as:

• Ramps

• Standard 2x4 boards (0.0381m by 0.0889 m actual cross sectional dimensions)

and textbooks for obstacle negotiation

• A straightaway for walking/running testing

• Stairs and large drops for falling and impact testing.

Two screenshots of the obstacle filled map are shown in Fig. 13.

36

Fig. 13. Pictures of the obstacle map that was created for testing the virtual robot.

These worlds were used to compare the virtual robot’s performance based on visual observation to that of the real vehicle. In this study, attention was focused on basic walking and running, and basic climbing over textbooks. The following metrics were used to evaluate the virtual robot’s performance:

• Top speed of about 0.9 m/s (~25 rad/s wheel-leg drive speed) without significant

end-over-end rotation or other adverse behavior. This corresponds to the vehicle

running at approximately 10 bodylengths/second.

• End-over-end rotation when attempting to climb up a wall at higher wheel-leg

drive speeds. At lower wheel-leg drive speeds, the vehicle should simply try to

“burrow” into the wall without making any forward progress. It is noted here that

in USARSim, vehicles are controlled by directly commanding a wheel-leg drive

speed, not a motor torque. A property called “MaxTorque” is used to specify the

maximum torque that the simulated vehicle can use to achieve a specified wheel-

leg drive speed.

37 • The ability to surmount obstacles (textbooks in this study) that are 0.04 m tall in

head-on and oblique angle (30o) approaches (Fig. 14). The 0.04 m obstacle height

here is slightly greater than 50% of the robot’s wheel-leg diameter.

30o Obstacle

Fig. 14. Top view of head-on and oblique approaches.

For this phase of testing, the iterative method described in Section 2.2 above was combined with the following procedure:

1. Baseline Performance Test: First, the virtual robot was run through a range of

drive speeds with an initial set of Karma Parameters. The goal of these runs was

to obtain performance data for an initial set of parameters for the purposes of

comparison with results that were obtained in the following steps of this

procedure. These tests were only done for walking and running. In the open

room, the vehicle was run through the following wheel-leg drive speeds: {0, 2,

10, 15, 20, 25, 30} rad/s.

2. Individual Karma Parameter Variation: Essentially, this step was used to

determine how moving in different directions of the parameter space affected the

virtual vehicle’s performance. After the baseline performance test, individual

38 Karma Parameters were varied through a range of values while leaving all other

parameters at their initial settings. For each value, the virtual robot was run

through the same set of drive speeds used in the baseline performance test. The

purpose of these runs was to obtain data that illustrated how each parameter alone

affected the vehicle’s performance.

3. Physical Reasoning: At this stage, physical reasoning was used to determine what

conditions would be required for the virtual robot to behave in a particular way in

order to explain its performance and the effects of individual Karma Parameters.

4. Karma Parameter Search: At this point, with an understanding of the effects of

different Karma Parameters, the method illustrated in Fig. 12 was used to improve

the virtual robot’s performance.

Essentially, the first 3 steps above seek to determine how and why different locations in

Karma Parameter space affect the overall performance of the robot with respect to some

initial reference point. The fourth step uses this knowledge to intelligently improve the

vehicle’s performance in the manner that is illustrated by Fig 12.

It is noted here that for the qualitative study, the vehicle was run on default simulation substrates. For these surfaces, the substrate’s physical properties are not necessarily known or controllable. Therefore, for this part of the study, the properties of the vehicle are tuned based on the observed performance of the real vehicle on tile. In the qualitative portion of the study, the problem of matching simulated and real world substrates is addressed, and elementary corrections are presented for a particular substrate. The specific rationale for testing the real and simulated robots on a benchmarked substrate is given in section 2.4.1.

39 For the qualitative study, the virtual robot was compared to physical observation

of a real Mini-Whegs™ robot. Video recordings of all simulation trials were recorded

using FRAPS* [44] video capturing software that was set to record at 30 frames per second (fps). In addition, the simulated vehicle’s instantaneous velocity, position in the map, orientation (i.e., local vehicle coordinate system orientation) with respect to the map coordinate frame, time, and speed change commands were logged to various files. The logged parameters were used to plot the vehicle’s speed and velocity components against time. Velocity components were reported in both vehicle (moving) and world (fixed) coordinates to help quantify the robot’s behavior. Steering was not used in any of the tests. Appendix I presents the mathematics behind plotting velocity components in vehicle coordinates.

2.4 – Quantitative Testing

After the qualitative testing was performed, quantitative test methods were

employed to gain a better understanding how well the simulation matched the

performance of the real robot and to improve the performance of the simulation if

necessary. As mentioned in section 2.3 above, in the qualitative testing, the substrates

that were used were default simulation substrates where the substrate properties are not

necessarily known. As stated in [27], both the robot and the test method that it is being

run through must be validated to ensure that an accurate comparison can be made

between the simulation and reality. Also, from experience, one would expect that the

vehicle will behave differently on substrates with different properties. As a result, in this

phase of testing, both the substrate that the robot is placed on and the robot itself are

tested and have their properties set to improve the performance of the vehicle. Also, for

40 this phase of testing, the torsional compliance of the simulated robot was set to a high

value such that it did not have any bearing on the robot’s performance. This step was

taken to improve the basis of comparison between the real and simulated robots since the

real robot does not have torsional compliance.

2.4.1 – Substrate Friction Testing

To evaluate the simulated vehicle’s performance on a pre-defined substrate, the

vehicle was made to walk on a Karma Actor that approximates the physical

characteristics of a real material. To design a Karma Actor that approximates the physics

of a real substrate, a real surface was tested in an inclined-plane setup (Fig. 15).

θ

Fig. 15. Illustration of the real inclined plane – block setup.

The substrate used was a Melamine surface on particle board. The plane and the rectangular block in Fig. 15 were made of the same material and thus have the same frictional properties. The angle of the plane (θ) was successively increased until the block began to slide down the plane under the following conditions

• Begin sliding with a small perturbation

• Slide down in some locations on the plane but remain stationary in others.

• Slide down the plane very slowly with a small acceleration

The angle under which these conditions hold is defined here as θThreshold. Essentially, this

test seeks to determine the angle at which the block begins to overcome static friction.

41 Tests were performed with the block as shown above and with the block attached to a 0.200 kg mass using double-sided scotch tape (for reference, the block itself is

0.0393 kg) (Fig. 16).

Fig. 16. Picture of the block with a 200g mass attached to it.

For both of these cases, the test results appeared to be relatively independent of the mass

of the block (i.e., the angle at which the three conditions above hold did not seem to be

altered by the addition of extra mass). This result is expected based upon Newtonian

mechanics (see Appendix II for details) and is important to note because the mapping

between the simulation mass and real-world mass is still under investigation. Therefore, a test where the mass does not explicitly need to be stated to obtain a result or a test where the final result is weakly dependent on mass is preferred to other means. Because this test appeared to be relatively independent of the mass, it was deemed acceptable to repeat it in USARSim.

42 Once the threshold angle was found, this test was repeated in USARSim. Fig. 17 illustrates the setup in USARSim, which consists of a Karma Actor that is the inclined plane, and a vehicle that is simply a rectangular block.

Fig. 17. Illustration of the simulated inclined plane setup.

Here, the inclined plane has an inclination angle that is equal to θThreshold. Because the

block and the Karma Actor substrate represent the same material, the KFriction of both actors was set to the same value and then iteratively modified until the block barely slid down the incline, or slid down the incline at a very slow rate.

A sliding test was attempted on the real inclined plane as well. In this test, the block was allowed to slide down the plane by a known length. The time it took for the block to move through a particular distance was recorded through the use of a high speed

video camera. Again, this test was performed both with the regular block and with the

block attached to a 0.200 kg mass. This test revealed that the time it takes the block to

slide down the plane on this particular material is mass dependent, which contradicts

43 what would be expected from a standard Coulomb friction model (see Appendix II for details). Because this test was mass dependent, it was not used in determining or verifying the KFriction value that was assigned to the substrate actor in USARSim.

In addition to the KFriction, the KRestitution of the substrate also needed to be set. This parameter was determined based on observations of collisions between the substrate and a falling object that impacted the substrate. In this setup, both the substrate and the falling block were made of the same material. It should be noted that the test used to determine the KRestitution value was qualitative in nature. A possible way to make the test more quantitative in nature is discussed in section 4.2.1.

Once the simulation’s substrate material properties were determined, a large rectangular platform was created for use as a substrate for robot testing. The material properties determined from the KFriction and KRestitution testing were assigned to this platform. The final map that was used for this phase of testing is shown in Fig. 18.

Fig. 18. Final map used in quantitative testing.

44 For both the friction testing and robot evaluation maps, beyond setting the correct

material properties, the ramp and platform simulation parameters were set such that they

remained fixed in the world regardless of contact from other objects. Testing indicated that this was extremely helpful in preventing adverse results from being generated. For example, when the robot spawns onto the substrate in the friction testing map, the impulsive force from the robot can force the substrate to move if the Karma Parameters that govern its attachment to the map are not appropriately set (spawning is the process by which an object instantiates into the world). Another approach to solving the problem of fixing the substrate in the world would have been to use the TERRAIN capabilities of

UnrealED (the word terrain is capitalized in this context to refer to UnrealED’s feature set). TERRAIN allows a user to create a landscape with features such as continuous and discontinuous hills and valleys (Fig. 19 - taken from [26]).

Fig. 19. Illustration of the type of landscape that can be created with UnrealEd’s TERRAIN functionality.

The surface properties of TERRAIN (KFriction and KRestitution) can be controlled in a similar manner to those of regular Karma Actors. Terrain by default is fixed in the world

45 (i.e., it does not react to the forces that an actor imparts to it, so it does not move). It was

decided that for this study, while a solution that uses TERRAIN may be more technically

correct, the Karma Actor approach would give comparable results with an easier

implementation. Appendix III details the full list of Karma Parameters that are used for

the substrate Karma Actor.

2.4.2 – Body Rotations

In this phase of the study, the standard validation procedure described in Fig 12

above is expanded on by extracting body rotations from the simulated robot and

comparing them with body rotations from the real robot. To obtain the robot’s body rotations, the vehicle’s orientation (i.e. the directions of its local coordinate axes)

throughout the course of a run is compared to its initial orientation. The differences in

orientation for each time step are used to extract Roll-Pitch-Yaw Euler Angles relative to

the initial orientation. The Euler Angles are used to establish the angle ranges that the

robot moves through. Here, the range is defined as the difference between the maximum

and minimum observed angle values, or

Range=−max( Angle Data ) min( Angle Data )

It should be noted here that data points that seem to be outliers (i.e. local simulation

instabilities) are excluded from this calculation.

Before proceeding, it should be noted that for the purposes of this analysis, roll and pitch are the angles of interest. Observations of real Whegs™ vehicles indicate that

depending on the substrate and the initial conditions of the robot and world, a given robot

can veer off to one side or another. As a result, the yaw angles that are obtained are not necessarily instructive in terms of benchmarking. Therefore, while yaw helps to indicate 46 the vehicle’s initial and final orientation with respect to its sagittal plane and may provide useful information in a more advanced analysis, it is not considered in the final analysis of this study.

In USARSim, the orientation information was obtained by implementing functionality in the Whegs™ class that outputs the vectors of the vehicle’s coordinate system for each instant in time. These vectors are relative to a nonmoving global reference frame (i.e., the coordinate frame of the map).

To obtain the body rotations of the real robot, high speed video footage was recorded of the real robot in basic walking at a set wheel-leg drive speed. The inspiration for this method of data collection and analysis comes from biological (particularly ethological) studies. In biology, high speed video is typically used to slow down movements in order to study, analyze and quantify motion [45-48]. Typically, high contrast points are marked on an animal that will be recorded during a particular motion or behavior. Once the animal has been recorded using high speed video cameras, motion analysis software is used to digitize and track the marked points through the motion sequence that the animal followed. Once a video has been digitized, various quantities such as positions, angles, velocities, and accelerations can be obtained. As an example,

Fig. 20 below shows selected frames from a video of a cockroach during a turn. The points track the animal’s joint positions throughout the course of the video. The line segments defined between each point are used to measure the angle between the two limbs as a function of time.

47

Fig. 20. Illustration of digitized high speed video footage. The red, blue, and teal points follow particular joints on the animal as the video progresses. The lines that connect the points illustrate how the angle between the two limbs under consideration changes over the course of the video.

To determine 3 dimensional distances from high speed video, two cameras are used to simultaneously view and record footage from a workspace. A calibration object

(whose dimensions are known) is used by the motion analysis software to determine correct 3D distances as seen by the two cameras based on their respective positions in the world, and the properties of the cameras themselves (e.g. focal lengths of the camera lenses). Once the calibration is done, video of the animal can then be digitized. With the calibration information, the software can determine the 3D positions of the points that have been marked on the animal for all instances in time. These data are used to determine velocities, angles and other quantities. An illustration of a typical high speed video setup is given below in Fig. 21.

48

Fig. 21. Illustration of a 3D high speed video setup.

For this study, to mark the robot so that the video could be digitized, points that represented the robot’s local coordinate axes were mounted to the front of the robot.

Also, a calibration object was made that spans the workspace of the robot for a given run

(Fig. 22).

Fig. 22. Illustration of a Mini-Whegs™ robot with points for digitization mounted to the front of the robot (left) and the calibration object that was used (right).

49 The points that were mounted on the front of the robot are made of Styrofoam balls and connected to each other with wooden dowels. The effects of the attached coordinate system’s mass and inertia on the robot’s dynamics were assumed to be negligible for the sake of simplicity. If this assumption is incorrect, then dynamics of the coordinate system could be factored in at a later point in the study by altering: the overall mass, center of mass, or the inertia tensor of the simulated robot.

The calibration object was made by using sheet-rock for the base and mounting

Tinker Toys™ to the sheet rock. Styrofoam balls were attached to the Tinker Toys™ so that the calibration object could be digitized. The workspace (and thus the calibration object) were designed to allow the robot to take approximately 10 to 15 steps (about 1.2 m), which allows the robot to reach steady state performance in terms of its cyclic body motions. To ensure that the coordinate system on the robot did not hit the substrate while the robot was moving, it was mounted approximately 0.0187 m above the top of the robot. The balls that were mounted on the robot were spaced 0.1266 m apart. To ensure that the calibration object completely contained the mounted robot points, the vertical spacing of the balls on the calibration object was set to 0.159 m. The calibration object was made to be nominally square to allow the robot to veer off course while still being able to maintain proper 3D distances within the camera views. The layout of the calibration object was designed to provide a good amount of interior resolution for determining correct 3D distances given a limited set of mounting poles. The overall maximum dimensions of the calibration object are given as follows:

• Height (as measured from bottom ball to top ball): ~0.159m

• Length (in the direction of nominal robot travel): ~1.2m

50 • Width (perpendicular to the direction of nominal robot travel): ~1.2m

Appendix IV provides a planar layout of the calibration object and the camera calibration

parameters that were used.

Two Photron® high speed video cameras were used to record footage of both the

calibration object and the robot. Using WinAnalyze Automatic Motion Analysis

software, the calibration object was digitized to determine correct three-dimensional

distances in the robot’s workspace based on the two camera views. Appendix IV gives

all of the camera calibration parameters that were used in determining an appropriate

calibration for each given run. Details on what each of the calibration parameters

represents are provided in [49]. After the calibration was completed, the points on the

robot were digitized over the course of a given run (Fig. 23).

Fig. 23. Illustration of digitized points that are used to extract body rotations from the real robot.

These points were used to create vectors that represented the vehicle’s local coordinate system. These vectors were then used to extract Roll-Pitch-Yaw Euler Angles. A combination of WinAnalyze’s auto tracking and manual tracking capabilities were used to track the robot’s points over the course of a given run. It is noted here that although

51 Fig. 23 illustrates 5 points that were mounted to the robot, only the three that are digitized in the figure are actually used. By digitizing and measuring these three points, two perpendicular vectors that are in the same plane can be created. Taking their cross product gives a third vector that is perpendicular to the first two, which establishes the vehicle’s coordinate system. This approach was taken instead of digitizing all five points to save time in the digitization process.

Before mathematically defining the Roll-Pitch-Yaw Euler Angles, the vehicle’s coordinate system needs to be known. For this study, a standard vehicle coordinate system was employed for both the real and virtual robots. This is illustrated in Fig. 24.

β -Pitch y

γ -Roll

x α -Yaw z

Fig. 24. Illustration of the coordinate system used in this study. x points out of the nose (front) of the vehicle, y points out of the starboard side of the vehicle and z points downwards. Roll, Pitch and Yaw are defined in a standard way based on these coordinates (Roll is about x, Pitch is about y, and Yaw is about z).

Roll-Pitch-Yaw Euler Angles were obtained using the following equations from [50]

52 β =−+Arctan2 r , r22 r ( 31 11 21 )

⎛⎞rr α = Arc tan 2⎜⎟21 , 11 ⎝⎠cos()β cos()β

⎛⎞rr γ = Arc tan 2⎜⎟31 , 33 ⎝⎠cos()β cos()β

β is the pitch angle about y, α is the yaw angle about z, and γ is the roll angle about x. rij corresponds to a particular element in the transformation matrix resulting from the following matrix multiplication:

⎡⎤ TC= [ Yaw−−− z]⎣ C Pitch y⎦[ C Roll x ]

T is the overall transformation matrix, and CEuler Angle-Axis is a rotation matrix for the

specified Euler Angle about that particular axis.

With angle information from both the real and simulated robots, a comparison

could be made to determine how to modify the simulation’s Karma Parameters to bring

the simulated robot closer to matching the movements of the real robot.

2.4.3 – Frequency Analysis

To extract frequency information, data (from both the real and simulated robot)

was first low-pass-filtered to remove unwanted high frequency content. Filtering was

performed using the Signal Processing Toolbox in MATLAB. Frequencies were

determined by taking a Fast Fourier Transform (FFT) of the filtered data and plotting a

power spectrum of the transformed data. The FFT and power spectrum were computed

53 using MATLAB’s built in FFT functionality. Extracting frequencies from USARSim

required additional steps beyond what was necessary to obtain frequencies from the real

robot. This was due to the variable sampling rate of UT2004. For the high speed video data, the sampling rate is constant and can be controlled by the user. In UT2004, the

sampling rate is hard coded into the software, and is lower than what was used in the

testing of the real robot. For reference, the nominal sampling rate of UT2004 is about

50Hz, whereas the sampling rate (or frames per second) of the high speed video was

about 250Hz. Also, the sampling rate in UT2004 appears to change depending on the

computations that are currently taking place in the simulation and the resources required

by other processes that are currently running on the system (e.g., the sampling rate can

decrease when the robot starts moving or when the video capture software is set to start

recording). To account for these issues, the average sampling rate of the simulation was

determined for a given time span of interest. The collected angle data was then

interpolated using this sampling rate to produce a set of data that has a constant sampling

rate. Frequency analysis was then performed on this new set of data to obtain an estimate

of the frequency observed in the simulation.

2.4.4 – Wheel-Leg Drive Speeds

For each run in this phase of testing, the real robot was throttled to the same speed setting (i.e., a given number of control stick clicks on the radio remote controller). To

ensure that the wheel-leg drive speeds were the same in both USARSim and the real

world, during the high speed video recording, close-up footage was taken of the robot during normal walking to observe the rotation of the wheel-legs. This video was used to determine the angular speed of the wheel-legs. This kind of test was done because it is a

54 better measure of how fast the wheel-legs rotate when the drive motor is loaded due to the weight of the robot. This wheel-leg drive speed was then used as the wheel-leg drive speed in USARSim.

2.4.5 – General Data Acquisition

Video recordings of all simulation trials were recorded using FRAPS™ [44] video capturing software that was set to record at 30 fps. Recorded parameters from the simulated robot were obtained by sending the appropriate data to various log files.

Steering was not used in any of the tests for both the real and simulated vehicles. All runs of the real robot were performed using freshly charged batteries for both the RC controller and the robot itself. As stated above, Photron® high speed video cameras were used to obtain high speed video footage. WinAnalyze Automatic Motion Analysis™ software was used to digitize the video and output raw kinematic data. Data was low-pass filtered using the Signal Processing Toolbox in MATLAB™. For this part of the study, the simulated torsional stiffness that is present in the wheel-legs was set to a high value

so that there was essentially no torsional compliance in the wheel-leg axles. This step

was taken because the real robot that the simulation was being compared to did not have

torsional compliance.

55 Chapter 3 – Results

This chapter outlines results obtained from USARSim and high speed video footage using the methodologies described above. Sections 3.1.1-3.1.3 describe results obtained from the initial construction of the virtual robot, and steps that were taken to remedy any apparent problems observed in the initial construction. Sections 3.1.4-3.1.6 describe results obtained from the preliminary benchmarking process (i.e. understanding the effects of individual Karma Parameters on vehicle performance and the set of Karma

Parameters that yielded acceptable virtual performance through visual observation).

Section 3.2 describes the results obtained from the quantitative testing procedure described above.

3.1 – Making the Robot and Qualitative Testing

3.1.1 – Dimensions Used In the Simulation

Initial testing (phases 1-3 of the procedure described in section 2.3) was done with a slightly larger vehicle. Phase 4 was performed with a smaller vehicle (Table 1).

Initial Dimension Final Dimension Body Length (m) 0.1143 0.09 Width (m) 0.09144 0.068 Height (m) 0.01905 0.02 Wheel-Legs Diameter (m) 0.096 0.0762

Table 1. Initial and final dimensions used in the simulation.

The latter dimensions were chosen because they more accurately reflect the size and performance evaluation basis of current Mini-Whegs™ robots. For example, the 10 bodylength/second speed listed above corresponds to a 0.09 m bodylength, so for this

56 performance metric, the smaller vehicle size is more appropriate. The study could have

been performed with the larger size vehicle since a real vehicle could be created that has

larger dimensions. The dimensional change is only used here for convenience in

comparing virtual and real performance. Appendix V contains a listing of the final

dimensions of all of the vehicle’s parts and the spacing between different components.

The spacing between each component is presented in data from the robot’s configuration

file.

3.1.2 – Functionality for Maintaining Proper Wheel Leg Phasing

During testing, it became apparent that new functionality would need to be added

to the “Whegs” class to ensure that the virtual robot maintained proper wheel-leg

phasing. Initially, when the vehicle spawned into a world, it would spawn properly with its wheel-legs out of phase, but then “fall” due to its mass such that the wheel-legs were in phase (Fig. 25).

Fig. 25. (a) Wheel-Legs are unable to maintain proper phasing without extra class functionality. (b) With proper functionality, the wheel-legs are able to maintain the correct phasing under all circumstances.

Occasionally, all of the wheel-legs would stay out of phase upon spawning such that the robot could be tested. However, if the robot was not stopped with the correct speed and

57 wheel-leg orientation, the wheel-legs would “fall” out of phase. This behavior appeared

to be independent of the torsional stiffness that was provided, and even occurred when the wheel-legs were connected directly to the chassis via a KCarWheelJoint. This was problematic because real Whegs™ robots maintain proper phasing even when stopped. It was determined that this problem was due to the nature of the KCarWheelJoint class.

This class rotates a given Actor about a spin axis by applying a torque to overcome

external torques. If the motor applies no torque, then the actor will be rotated about the

motor’s spin axis by all other external torques. Physically, a KCarWheelJoint is

analogous to having an axle that rotates a wheel mounted on a frictionless bearing. Real

Whegs™ robots have a drive train that connects each wheel-leg to a single drive motor

and torsional springs that are pretensioned which causes them to maintain proper phasing

even when the motor is not running. To fix this problem, a member function was added

to the “Whegs” class that forces the KCarWheelJoint to achieve zero angular velocity by

using a preset torque value when the robot is stationary (drive speed = 0 rad/s). This

solution appeared to solve the problem.

3.1.3 – Wheel-Legs Behaving as KActors vs. KTires

Initially, as stated above in section 2.1 the wheel-legs were implemented as

KTires. However, when attempts were made to run the robot, the wheel-legs would rotate but not cause the robot to translate, resulting in the wheel-legs spinning in place and the robot itself not making any forward progress. It was determined that because the wheel-legs were not connected to KCarWheelJoints, KActor properties were used instead of KTire properties. The default KActor friction value was zero, which led to the wheel- legs sliding on a given substrate. An attempt to rectify this problem was made by

58 implementing the solution proposed in section 2.1 above: making each spoke a KTire that was connected to the central hub via a KCarWheelJoint. Because of the problems experienced in maintaining proper wheel-leg phasing mentioned in the section above, a function was added to the “Whegs” class that forces the spokes to maintain their initial orientation relative to their parent hub. This solution resulted in the wheel-leg spokes drifting into altered positions over the course of a given run, particularly at higher drive speeds (Fig. 25).

Fig. 26. Implemented as KTires, the wheel-leg spokes drift out of the correct position over the course of a run.

An attempt to remedy this problem was made by increasing the torque used to maintain the spoke orientation. This resulted in the vehicle going through nonphysical end-over- end rotation at higher wheel-leg drive speeds (about 15 rad/s and higher) while still translating forward, and did not appear to remove the drifting problem. It was found that the only apparent way to influence the problem was to increase the vehicle’s inertia tensor or angular velocity resistance (KAngularDamping) Karma Parameters. These parameters only seemed to slow down the rotation. They also had to be raised to levels much higher than that of any other vehicle in USARSim, including vehicles that are more massive and should have much more inertia, such as the Hummer.

59 The nonphysical nature of this behavior and its solution prompted allowing the wheel-legs to behave as KActors instead of KTires. This approach resulted in behavior that appeared to be more physically relevant when compared to the real vehicle. Also, as stated above, because this approach offers a narrower parameter search and because the wheel-legs on Mini-Whegs™ vehicles are not formal tires, it was felt that using the wheel-legs as KActors would provide a reasonable approximation that would allow for relatively simple but effective validation.

3.1.4 – Effects of Individual Karma Parameters

The virtual robot’s speed and velocity components were plotted in both world and vehicle coordinates. These plots were used as a tool to help examine the effects of individual Karma Parameters on the robot’s performance. Example plots are shown in

Fig. 27.

60

Fig. 27. Example plots of velocity component magnitudes expressed in vehicle coordinates (top) and world coordinates (bottom). In vehicle coordinates, x is forward, y is starboard, and z is out the bottom of the vehicle. The absolute value of the velocity components is plotted here for comparison with the speed. In both plots, x velocities are represented in red, y in green, z in pink, and overall speed (magnitude of the velocity vector) in blue. In the vehicle coordinates, the x component of velocity has the highest contribution to the overall speed, as one would expect.

61 The vertical black lines are the times at which speed change commands were issued. The

initial speed (which occurs around 15 s in the plots in Fig. 27) is due to the vehicle spawning into the world (the vehicle initially spawns into the world at some height above

or below the floor, comes to rest and then remains at rest until a command is issued from

the user). By looking at the vehicle coordinate velocity plot, it can be seen that the x-

component of velocity in the vehicle coordinates is nearly identical to the speed, meaning

that the vehicle is making forward progress and not translating to its left or right. In

addition, there is a point around 65 s where the x-velocity and the speed both drop while

the z-velocity spikes. Upon comparison with the video data captured by FRAPS™, it

was observed that this was the location at which the robot flipped over, or end-over-

ended. This kind of feature was present in all cases where the robot went through an end-

over-end rotation. The world coordinate plot illustrates the vehicle’s tendency to move in

a particular direction within the world. In this plot, the robot’s initial heading mostly in

the Y direction. However, after it flips over at around 65 s, it also begins to have motion

in the X-direction as well. In addition to these kinds of observations, the data in the plots can be used to look at other phenomena such as the average speed of the vehicle for a given time interval and the variability of the data about this average.

The following Karma Parameters were singly modified while leaving all other parameters at their initial settings to determine their effects on the performance of the vehicle:

• ChassisMass (Chassis KMass): This is the mass of the chassis (i.e., the

rectangular block that serves as the body of the vehicle). With the initial

parameters that were set, it was found that altering this parameter did not appear

62 to have a large impact on the overall performance of the vehicle in terms of being

able to reach a top speed, or end-over-ending. The lack of effect of the

ChassisMass was due to the fact that initially, its value was very small compared

to the masses of the spacer plates, which are discussed next.

• Spacer plate KMass: This is the mass of the spacer plates. This mass was varied

to determine the effects of raising and lowering mass that is not coincident with

the vehicle’s center of mass. Initially, the mass of the chassis was very small,

both compared to the spacer plates, and in an absolute sense, so this test also

revealed how the vehicle’s overall mass affected its performance. When these

masses were lowered to a value of 0.002 in the Unreal Unit System, the vehicle

began to end over end at higher wheel-leg drive speeds (10 rad/s and over). At

mass values of 2 in the Unreal Unit System, the vehicle appeared to perform in a

relatively predictable manner with only occasional end-over-end instances

occurring at drive speeds between 25 rad/s and 30 rad/s. Raising the mass of the

spacer plates effectively raises the mass and inertia of the vehicle about its

principal axes since the masses are concentrated at the four corners of the chassis.

• KFriction: This is the friction present in the wheel-legs. It was found that, as one

would expect, higher values of friction (10 in this study) resulted in the wheel-

legs not slipping on the substrate as much during walking. Visible slippage

occurred with lower friction values (0.5 in the Unreal Unit System). Both of these

friction values yielded roughly the same average translational speed for a given

wheel-leg drive speed. However, the variation about the average was much

higher for the larger friction value. This was attributed to stronger braking forces

63 in the step cycle. The wheel-legs provide both propulsive and braking forces,

where braking occurs in the beginning of the stance phase, and propulsion occurs

towards the end. Because the friction value is higher, both the braking and

propulsive forces are increased. As a result, during touchdown and in the

beginning of the stance phase, the wheel-leg will have a greater tendency to retard

the vehicle’s motion. However, towards the end of the stance phase, the wheel-

leg will provide more thrust to propel the vehicle forward.

• KRestitution: This parameter, which is assigned to individual actors in UT2004, is

similar in concept to the coefficient of restitution used in collision analysis. A

value of 1 corresponds to an “elastic” collision between two objects (i.e. an

object’s incoming velocity is equal to its outgoing velocity). Values less than one

result in increasingly inelastic collisions. At a KRestitution value of 1 in the

Unreal Unit System, as the wheel-leg drive speed was increased, the vehicle

appeared to have increasingly elastic collisions with the ground. The vehicle’s

translational speed appeared to reach a relatively constant value that became

independent of the wheel-leg drive speed. As a result, the vehicle’s average speed

at higher drive speeds seems to flat-line when compared to other tests. The

average speed also had a great deal of variability for each wheel-leg drive speed.

• Torsional Stiffness: The torsional stiffness of the rear wheel-legs was set to 250 in

the Unreal Unit system for all runs. This value appeared to make the back wheel-

legs rotate with the spacer plates under all circumstances (i.e., no torsional

compliance). The torsional stiffness of the front wheel-legs was varied to see how

adjusting the stiffness affected their motion and the vehicle’s performance. As

64 expected, higher values of stiffness resulted in the wheel-legs behaving more like

conventional wheels, whereas low stiffness values allowed the spring to “wind

up” before rotating the wheel-legs. Excessively low values of stiffness caused the

wheel-legs to fall out of phase when the vehicle was spawned. At these low

stiffness values, when a drive command was given, initially, the wheel-legs would

not rotate. However, after the springs were deflected sufficiently, they would

rotate the wheel-legs forward to release the tension as one would expect.

3.1.5 – Qualitative Karma Parameter Search

After the effects of the above mentioned parameters were understood from the single parameter variations, testing was done to make the virtual robot’s performance more closely match the real robot’s performance. Table 2 indicates the parameters that were changed. See Appendix V for the final listing of all of the Karma Parameters for all parts of the vehicle after the qualitative study.

Karma Parameter (Unreal Unit System) Initial Value Current Value Chassis ChassisMass 0.00342 0.75 MaxTorque 32000 50 MotorTorque 2400 50 KCOMOffset (X, Y, Z) 0 0.04464 KCOMOffset (X, Y, Z) 0 0 KCOMOffset (X, Y, Z) 0 0 Wheel-legs Wheel-Leg Kfriction 1 0.75 Wheel-Leg KRestitution 0 0.1 Wheel-Leg Kmass 0.0008 0.08 Spacer Plate Spacer Plate Kmass 1 0 Spacer Plate KInertiaTensor(0) ~ Ixx 0.0035 0 Spacer Plate KInertiaTensor(3) ~ Iyy 0.0066 0 Spacer Plate KInertiaTensor(5) ~ Izz 0.0035 0 Table 2. Karma parameter values before and after the qualitative study.

65 In Table 2, column 3 is a listing of the initial values of the Karma Parameters. Column 4

shows the values that the parameters were changed to after testing. As can be seen from

Table 2, the following general changes were made. First, because spacer plates are not found on the real robot, their mass and inertia values were set to zero so that they would have no effect on the dynamic characteristics of the simulated vehicle. Based on the results obtained from varying individual Karma Parameters, lowering the mass of the

Spacer Plates caused severe end-over-ending of the vehicle. This prompted raising the

ChassisMass property of the vehicle to 0.75 in the Unreal Unit System, which drastically reduced this problem. Based on testing of an actual Whegs™ robot on tile, it was observed that the wheel-legs can slip during walking at higher speeds, similar to what can occur with lower values of the KFriction parameter. The real vehicle also appeared to have a degree of elasticity with the ground, similar to when the KRestitution values were raised. Accordingly, the KFriction and KRestitution values were lowered and raised respectively. The center of mass of the vehicle (KCOMOffset) was not varied in the single parameter variation study. However, after examining a particular Mini-Whegs™ vehicle, it was found that many of the components such as the steering servo, steering

mechanism, and battery are located towards the front of the vehicle. Also, the virtual

vehicle still went into end-over-ending behavior more than was desired. Therefore, the

KCOMOffset value was adjusted to bring the center of mass of the vehicle slightly forward. This reduced the end-over-ending behavior slightly, but did not completely remove the problem. While the center of mass is not typically in the forward section of a

Mini-Whegs™ vehicle, the change was made here to judge its impact on the simulated vehicle’s performance. In addition to these parameters, the KCarWheelJoint motor

66 torque and wheel-leg masses were also changed. The motor torque was ultimately lowered from its initial value of 2400 to 50 in the Unreal Unit System to give the vehicle

a more realistic level of drive torque (for comparison, the Hummer uses a motor torque

value of 2400). The wheel-leg masses were raised from 0.0008 to 0.08 (Unreal Unit

System).

3.1.6 – Performance Results

The parameter changes that were made appeared to move the virtual vehicle

towards matching the performance of the real vehicle. With the final set of parameters

given in Table 2 above, the robot was able to run at near top speeds with occasional end-

over-ending. It was also able to end-over-end at walls with higher wheel-leg drive speeds

(10 rad/s and up), which is normal Mini-Whegs™ behavior. In climbing tests, the robot

was able to successfully surmount a 0.04 m obstacle in both head-on and 30o approaches.

3.2 – Quantitative Testing

3.2.1 – Substrate Friction Testing Results

Based on the quantitative methods described above, the threshold angle of the

o material used for the inclined plane surface was found to be θThreshold = 11.79 . Upon

incorporating this information into the simulation, suitable values for the KFriction and

KRestitution of the simulated substrate were found to be 0.85 and 0.9 respectively. Table

3 shows these parameters along with other parameters that were set for the substrates to

give them the proper physical and world-relevant characteristics (e.g. having the correct

value of friction and not moving upon collision with the vehicle or test block).

67 Property Value KFriction 0.85 KRestitution 0.9 bHardAttach TRUE KMass 5 bBlockActors FALSE

Table 3. Karma Actor substrate properties.

3.2.2 – Results from the Real Whegs Robot

Using the high speed video footage of the real robot and the calibration data obtained from the calibration object, the points mounted on the robot were digitized and used to determine the 3D coordinates of each point over the course of a run. A sample plot of the 3D coordinates from WinAnalyze is given in Fig. 28.

Fig. 28. Sample plot of 3D coordinate data. This particular plot shows the 3D coordinates of the front point that is closest to the robot. Note that the X-Y-Z coordinates above correspond to the representation of the front point coordinates in the global reference frame. In the global frame used by WinAnalyze, Y points downward towards the ground, Z points in direction that the robot is set to initially travel in (initially aligned with the vehicle’s x axis), and X is initially aligned with the vehicle’s y axis.

68 The high frequency oscillations in the 3D coordinate data above (specifically in the x and y coordinates) are due to the coordinate system on the robot not being entirely rigid (i.e., the coordinate system’s stiffness allows it to bend under certain conditions). Upon examining the video, it was determined that the oscillations do not contribute to the overall measured range of excursion of the robot during the course of the run, and should not corrupt the data. In the worst case scenario, we would obtain an overestimate of the range of angles that the vehicle moves through. Even this kind of over estimate will not be much greater than the actual angle range. In light of these considerations, no corrective action was taken to remove this component of the signal.

From the 3D coordinate data, the Pitch-Roll Euler Angles were extracted as described above. Fig. 29 shows a sample plot of the Pitch and Roll Angles over the course of a run.

Pitch Angle (Theta) vs. Time 15

10

5

0 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Pitch Angle (degrees) Angle Pitch Time (s) Roll Angle (Phi) vs. Time 15

10

5

0 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Roll Angle (degrees) Angle Roll Time (s)

Fig. 29. Sample plot of Roll and Pitch Euler Angles from the real robot. The large peaks in the beginning represent a startup transient that results from the robot overcoming the static torque imposed on the motor by the robot’s mass, and accelerating up to steady state walking. For this study, the robot’s steady state behavior is considered while the startup transient is ignored.

69 In these and subsequent plots, the angle values are shifted such that the lowest

angle value is zero. This is done for convenience in determining the angle range. It

should be noted here that extreme values that appear to be outliers (e.g. local anomalies

in the simulated data) are ignored in determining the angle range.

It was found that the angle range that the real robot tends to traverse is about 10 to

12 degrees in both Pitch and Roll with a wheel-leg speed of 11.95 rad/s. The dominant frequencies of both Roll and Pitch were measured to be on the order of 5 to 5.5 Hz.

3.2.3 – Results from the Simulated Robot (USARSim)

Given the angle range information from the real vehicle, it is possible to alter the

parameters of the simulated robot to move its performance towards that of the real robot.

To frame the benchmarking process, a starting point was first established. Fig. 30 shows

Pitch and Roll Euler Angles that were recorded by using simulated robot data that were

obtained during the preliminary benchmarking process [28].

Pitch Angle (Theta) vs. Time 10

5

0 52 53 54 55 56 57 Pitch Angle(degrees) Time (s) Roll Angle (Phi) vs. Time 10

5

0 52 53 54 55 56 57 Roll Angle (degrees) Time (s)

Fig. 30. Plot illustrating the angle range of the simulated robot with the Karma Parameters that were found in the quantitative study.

70 As can be seen, the cyclic angle range of this data does not match the angle range obtained with a real robot (at most, the angle range here is about 6 degrees). Based on the qualitative study [28], the following parameters would be expected to have some bearing on this particular aspect of performance:

• Wheel-Leg KFriction – This parameter being higher could increase the angular

range that the robot is capable of reaching by increasing the force that is imparted

to the vehicle upon wheel-leg touchdown.

• Wheel-Leg KRestitution –This value being set too low could result in weak

collisions between the wheel-legs and the substrate, which would result in

undershooting the angular range that should be traversed.

• Chassis/Wheel-Leg KMass –This value being set too high could limit how much

the vehicle is able to rotate about each wheel-leg due to a higher moment about all

of the wheel-legs from the weight of the robot.

• Chassis KInertiaTensor – This parameter controls the inertia of the vehicle about

its principle axes. A larger inertia tensor value results in the vehicle providing a

stronger resistance to rotation about that particular axis. The inertia being set too

high could limit the angular range that the vehicle is able to move through.

For the purposes of simplicity, benchmarking is attempted by only changing the chassis/wheel-leg Kmass, wheel-leg KRestitution and wheel-leg KFriction. This approach leaves out the inertia tensor, which reduces the complexity of the search.

By iterating on these parameters, the performance of the simulated robot was brought closer to that of the real robot. Table 4 provides a table of the initial and benchmarked Karma Parameters that were used in the simulation. Fig. 31 shows a

71 sample plot of the Pitch and Roll Euler Angles for the benchmarked parameters. Fig. 32 shows sample plots of the power spectra from both the real and simulated robots for Roll and Pitch.

Property Initial Value Current Value ChassisMass 0.75 1 KFriction 0.75 0.95 KRestitution 0.1 0.85

Table 4. Initial and final values of Karma Parameters for the chassis and wheel-legs after the quantitative study.

Pitch Angle (Theta) vs. Time 15

10

5

0 42 44 46 48 50 52 54 Pitch Angle(degrees) Time (s) Roll Angle (Phi) vs. Time 20

10

0 42 44 46 48 50 52 54 Roll Angle Roll Angle (degrees) Time (s)

Fig. 31. Sample plot of Pitch and Roll Euler Angles.

72 Frequency content of Pitch Frequency content of Roll 0.25 0.25

0.2 0.2

0.15 0.15

0.1 0.1

0.05 0.05

0 0 0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140 frequency (Hz) frequency (Hz) a

Frequency content of Pitch Frequency content of Roll 0.025 0.025

0.02 0.02

0.015 0.015

0.01 0.01

0.005 0.005

0 0 0 5 10 15 0 5 10 15 frequency (Hz) frequency (Hz) b

Fig. 32. Sample plots of Pitch and Roll power spectra for the real robot (a) and the simulated robot (b). As can be seen, because the simulated robot has a non-constant sampling frequency that had to be accounted for, the data is much noisier for the simulated robot.

Extracted angle ranges from the simulated data were on the order of 10-11 degrees for both Pitch and Roll. The simulated roll frequency was on the order of 5.5 Hz, which agrees with the measurement taken from the real robot. The simulated pitch frequency was on the order of 1 Hz, which does not match the real robot. Also, as can be seen from

Fig. 32, the power spectra for the simulated robot are much more erratic, suggesting that the data from the simulated robot is much noisier. Possible explanations for the pitch frequency discrepancy and the quality of the power spectra from the simulated robot are described in Section 4.1.

73 Chapter 4 – Conclusions, Discussion, and Future Work

4.1 – Conclusions and Discussion

In summary, in the work that has been presented here, basic functionality

modifications of existing USARSim parent classes along with functionality implemented

in the newly defined “Whegs” class appeared to successfully replicate some of the

general behaviors of Whegs™ robots, namely torsional compliance and proper wheel-leg

phasing. Through a qualitative study, Karma Parameter modification based on physical

reasoning and observation of a real robot through standard video footage, visual

observation and direct interaction appeared to result in improved, more realistic

performance of the virtual robot in basic walking, running and climbing. In addition, the

procedure used in the parameter modification yielded insight into how each individual

Karma Parameter contributes to the overall performance of the simulated vehicle. The

velocity history of the virtual vehicle in world and vehicle coordinates along with the

robot’s average translational speed for a given input wheel-leg drive speed was recorded

and used to determine if the virtual vehicle was able to attain specific translational

speeds, the degree to which the virtual vehicle collides with the ground, and the vehicle’s

tendency to rotate end-over-end during normal walking.

The quantitative study presents a performance improvement for the simulated

Whegs™ robot based on quantitative data captured from a real robot on a known

substrate. By modifying a limited set of Karma Parameters based on the principles of

dynamics, the performance of the simulated vehicle was tuned to better match the performance seen in the real vehicle. While a future study would enable a more thorough

74 Karma Parameter search involving the full parameter space, the results shown above

illustrate that improvements can be made by modifying only a few parameters.

Of the four quantitative performance metrics used (Pitch and Roll range and Pitch

and Roll frequency) the Pitch frequency was the only metric where there was a large

discrepancy between the simulation and reality. One explanation for this discrepancy is that there may be phenomena that are present in the real robot that are not being captured

by the simulation. For example, the real robot has non-zero tolerances in the construction of its wheel-legs and in the attachment of the wheel-legs to the chassis that are not present in the simulated robot. Also, the real robot’s wheel-legs are not exactly 60o out of phase. These kinds of differences between the real and simulated vehicles could be responsible for differences in the observed frequencies. Another explanation is that more of the Karma Parameter space needs to be examined. For example, by moving the center of mass (COM) forward and up from its initial position (for reference, recall that the initial COM was slightly forward of the center of volume of the vehicle), the simulated pitch frequency was moved towards the value observed in the real robot (the value increased from ~1Hz to ~2.5Hz). This suggests that the vehicle’s mass, mass distribution and inertial properties need to be analyzed and more accurately tuned. It also suggests that even though one may expect the robot’s dominant frequencies to be mostly based on kinematics, the dynamics of the robot can have an impact on its oscillatory characteristics. If the center of mass and any other relevant dynamics characteristics (e.g., the inertia tensor) of the simulated vehicle are corrected to improve the pitch frequency, then the above quantitative study would need to be repeated to ensure that the angle

75 ranges and Roll frequency remain correct given the new mass information. This process would bring the simulation closer to matching reality.

In addition to the Pitch frequency discrepancy, the frequency data from the simulation (in both pitch and roll) is much noisier than the data from the real robot. This is most likely due to the fact that the sampling rate in UT2004 is not constant, and was therefore accounted for by interpolating the data. Unfortunately, there does not appear to

be any way to change the sampling rate or to ensure that it remains constant during a run.

Even if the sampling rate can be altered or controlled by the user in some way, this would

be a modification that would have to be made in a high level UT2004 base class, which

would affect both USARSim and the game itself. Any change that is made at this level

would need to undergo thorough testing to ensure that the change that is made does not

have adverse effects on the operation of the game, and therefore, the simulation.

Despite the pitch discrepancy (which suggests that more of the parameter space

needs to be searched and tuned) and the noisy data from the simulation, this study as a

whole illustrates that by using quantitative data and modifying a small number of

parameters, the performance of the simulated vehicle can be improved over the results

that are obtained from a purely observation based study. The results generated from the

quantitative study could not have been obtained with visual observation alone.

Beyond benchmarking the particular vehicle used in this set of experiments, this

study provides a framework with which any simulated Whegs™ vehicle in any

simulation package can be evaluated. This presents the possibility of putting a fleet of

Whegs™ vehicles into USARSim (or another package depending on the purpose of the

simulation), using the methods described above to benchmark them, and then using these

76 simulated vehicles as the starting point for performance evaluation, new design concepts

and end-user training scenarios. The Whegs™ robots that are incorporated into the

USARSim environment can be run through standardized test methods (such as the

different arenas developed by the National Institute of Standards and Technology – [18,

34]) to predict the performance of the real robot in various real-world scenarios.

4.2 – Future Work

With the studies that have been performed date, a variety of steps can be taken to

yield further advancements. These steps can be divided into “Whegs™ Specific” items,

and “USARSim and Other Applications”.

4.2.1 – Whegs Specific Items

In terms of Whegs™, a variety of steps can be taken to advance and improve the

work that has been presented here. One improvement that can be made is in substrate

testing. Because the substrate’s properties can have a significant impact on the vehicle’s

performance, a future study would need to develop a benchmarking method that allows

both the friction and the elasticity (i.e., KRestitution) of the substrate to be quantitatively

determined. As mentioned above in section 2.4.1 above, the test that was used to determine the simulated substrate’s KRestitution Karma Parameter was qualitative in

nature. For a future study and further benchmarking of the simulation, a test needs to be

developed that allows the user to quantitatively determine a KRestitution value that is

physically relevant. This could be done by implementing a test setup (both in the real

and virtual worlds) that uses a device to drop an object onto a substrate in a repeatable

manner. The object and the substrate would be made of the same material as in the tests

presented above. High speed video could be used to record the height that the object

77 rebounds to. This test could then be repeated in USARSim and used to determine a

KRestitution value that gives comparable results to what is observed in the real world.

With quantitative methods in place for determining a virtual substrate’s

simulation parameters, the real and virtual robots could also be tested on multiple

substrates. It is conceivable that, even though reasonable results were found on the

substrate used in this particular study, tests from a different substrate may yield

undesirable results since there could be inaccuracy in how the combination of substrate

and vehicle simulation parameters was set for the study above. Essentially, one would

like to avoid the possibility of incorrectly setting the properties of the substrate, and then

compensating for this by incorrectly setting the simulation parameters of the vehicle.

Testing the vehicle on tile, carpet, concrete and a variety of other materials by using the

same quantitative test for each material would help to guard against this kind of

benchmarking error. If the vehicle’s parameters are correctly set, then for any properly

benchmarked substrate, one would expect data from the simulation to agree with data

from reality for a test on that particular substrate.

Another task that could be undertaken for the virtual Whegs™ vehicle is to

implement the use of an actual RC Controller as the mechanism through which the

simulated vehicle is controlled. As stated in section 1.4 above, two of the purposes for

implementing a Whegs™ robot in USARSim are to allow developers to test robots in

real-world scenarios, and to allow end-users to increase their skill level on the robot

without having to use a real vehicle. One way in which these goals can be achieved is to

ensure that the user has access to simulation controls that mirror what they would see

with the real robot. By implementing an actual RC controller into the simulation, users

78 would be able to control a virtual Whegs™ robot in the same way that they would control

a real robot (i.e. throttling a control stick to accelerate or decelerate the robot, using

another control stick to activate the body joint or steer, and using the other switches, dials

and control sticks for other relevant purposes). Beyond implementing an RC controller,

various types of sensors available in USARSim along with custom autonomous controllers could also be implemented into the virtual vehicle. Studies such as those

performed in [40, 41] could then be performed in the simulation in various environments

under various conditions.

In addition to determining better ways to benchmark the simulation and

implementing RC and other types of control, work can be done to refine how the

simulated robot is constructed. Currently, the simulated vehicle exhibits Whegs™

behaviors and functionality. However, the way in which the behavior was achieved in

the simulation does not exactly mirror what is done in reality. As stated in section 3.1.2

above, Whegs™ robots have one drive motor that is connected to and drives all of the

wheel-legs (this is responsible for the nominal wheel-leg phasing even when the robot is

stopped), and each wheel-leg has a torsionally compliant device to allow for passive gait

adaptation. The main difference between the real robot and the simulated robot is that

each wheel-leg in the simulation has both a torsionally compliant device and a motor.

The functionality that has been imparted to the “Whegs” class allows the simulated

vehicle to mirror reality from a behavioral standpoint. However, a future work could

focus on redesigning the “Whegs” class such that there is one motor that controls all of

the wheel-legs. The ideal case would be an implementation where there is one motor that

is connected to all of the wheel-legs through a virtual drive train. This would more

79 accurately reflect real Whegs™ construction, and may allow for possibilities such as pretensioning the torsionally compliant devices and limiting their range of motion in the simulation.

In addition to the items above, from a software development standpoint, future work could also be taken to “clean up the code”. Currently, simulated Whegs™ functionality depends on code that has been added and modified in both the “Whegs” class and its parent classes. In an ideal world, all of the functionality for the simulated

Whegs™ robot would be in the “Whegs” class. This would effectively localize all of the functionality of the simulated Whegs™ vehicle, meaning that, if changes need to be made, they can be made in one particular class versus having to modify a number of classes (including those which help to control other parts of the simulation).

4.2.2 – USARSim and Other Applications

As stated in the introduction, an idea that must always be at the forefront of any study that involves a simulation package is that the simulation is only an estimate of reality. As a result, the range of applicability of the simulation and the physical meaning of its results must always be considered and carefully scrutinized. One step that would address this issue and benefit simulation efforts for all robots in USARSim is a formalized benchmarking study of the Karma Physics Engine itself against canonical dynamics problems. Known problems such as multilink pendulums and problems where quantities such as energy and momentum are conserved could be simulated in the

USARSim environment. The results could then be compared to solutions that have been obtained from “industry standard” software (such as Visual NASTRAN 4D and

ADAMS) and custom codes. This would provide insight into the accuracy and limitations

80 of USARSim, and insight into how the Karma Parameters map to reality. Mapping the simulation parameters to real world quantities would enable developers of virtual robots to more easily and accurately design and test their robots with increased levels of performance. In terms of the limitations that may be found, although there may be regions of the parameter space that yield unrealistic or incorrect simulation results, this kind of study would provide an understanding of what the exact ranges are and the effects of certain parameter space configurations on the simulation, thereby enhancing

USARSim’s usability and utility. For this particular study, a benchmarking of USARSim would allow for a wider range of tests to be used to validate the substrate and the robot, since more quantities could be accounted for. As an example, if the USARSim mass parameter is mapped to real world mass, then tests that are performed in both the simulated and real worlds can be mass dependent, which would increase the number of tests that can be performed and the number of quantities that can be obtained from the tests.

With a Whegs™ robot successfully and accurately implemented in USARSim, one direction that can be taken is to use the simulation to perform group behavior studies.

Group behavior has a wide variety of current and potential applications. As discussed in section 1.1.1 above, [1, 2] investigated applying group behavior techniques to Mars

Tumbleweed Rovers. A drawback to this work was that the group behavior component of the study was done outside of the dynamic simulations. That is, the dynamic simulation software was only employed to generate data that was used as an input for the stochastic group behavior simulation. Combined with the MOAST control software,

USARSim offers the possibility of performing a group behavior study on a physically

81 relevant virtual vehicle within a dynamic simulation environment. In essence, this offers

the possibility of simulating a number of physically relevant vehicles in a physically

relevant environment and directly observing the results without having to make or

maintain a number of real world vehicles. By using a benchmarked vehicle, the user can

have confidence in the results that are obtained.

With a Whegs™ robot simulation in place, another step that can be taken is to

develop a Micro Morphing Air and Land Vehicle (MMALV) in USARSim. MMALV is

a project that seeks to combine the Whegs™ ground vehicle technology from Case

Western Reserve University with the flexible wing micro air vehicle technology from the

University of Florida [51, 52]. The idea behind MMALV is to develop a vehicle that is capable of functioning as a remote sensor platform for hazardous situations by executing the following tasks:

• Deploy from a command center and fly to a target zone

• Land and convert to a ground mode

• Walk around, gather and relay information back to the command center

• Reconfigure to the aerial mode

• Take off and fly back to the command center or to another target zone

MMALV can be used by first responders for search and rescue operations, or by

military and security personnel for surveillance purposes. By implementing MMALV into USARSim, end users would be able to develop their skills in terms of operating the vehicle. A simulation would also be of particular use to developers. The particular nature of this project results in a great deal of trial and error experiments despite careful

design. For example, once an aircraft has been designed and constructed, preliminary

82 flight testing must be performed to properly trim the vehicle. During this phase, the vehicle is subject to crashing. If the vehicle crashes and is damaged, then it must be repaired and possibly altered before it can be tested again. This gives rise to not being able to test a vehicle under repeatable conditions. A simulation would allow users to test and trim vehicles in simulation. Once the trim parameters are set, the real-world vehicle could then be trimmed and brought directly to actual flight testing.

83 Appendix I – Converting Velocity from World to Vehicle

Coordinates

The position vector to the vehicle from the fixed world coordinates is given as K K rR= K KKK rRiRjRk=++x yz

Differentiating with respect to time gives the velocity as K K K K   rRiRjRk=++x yz

This equation represents the vehicle’s velocity in the world coordinates. However, it must also be represented in the vehicle coordinates. Let the world coordinates be K represented by the unit vectors ijk,, or I , and let the vehicle coordinates be K represented by eeex ,,yz or E . The two coordinate systems can be related to each other by the following equation K K E = TI  K K Where T is a 3x3 transformation matrix that rotates I to E and has the form 

⎡TT T⎤ ⎢ eixx→→ e j ek x →⎥ TT= T T ⎢ eiyy→→ e j ek y →⎥  ⎢ ⎥ TTT ⎣⎢ eizz→→ e j ek z →⎦⎥

Each element of the matrix T has the following form 

84 Tab→ = cos( anglebetween a and b) K K By measuring the unit vectors I and E , the matrix T can be computed. Once this  matrix is known, the velocities can be expressed in both world and vehicle coordinates.

85 Appendix II – Dynamics of a General Inclined Plane

Consider the following free body diagram of a block on an inclined plane.

Summing the forces in the x and y directions respectively yields the following

∑Fx =−=WFmasin(θ ) fr x

∑FNWy =−cos()θ = 0

The weight (W) of the block is equal to its mass times the acceleration due to gravity,

which gives

Wmg=

∑Fx =−=mgsin()θ Ffr ma x

∑FNmgy =−cos()θ = 0

Also, the standard Coulomb friction model is given by

86 Ffr = μN

Solving for the acceleration of the block in the x direction gives the following

∑Fx =−=mg sin(θ ) Fmafr x F →=agsin()θ −fr x m

If the Coulomb friction model is inserted into this equation, the following result is obtained

F μN ag=−=−sin()θθfr g sin() x mm

∑FNmgy →= cos()θ

μθmg cos() ag=−sin()θ x m

→=agx ()sin()θμ − cos () θ

As can be seen from these results, with a simple Coulomb friction model, the acceleration

(and thus the position) of the block vs. time does not depend on its mass. However, if the friction that is present cannot be described using Coulomb friction alone, then in general, the acceleration of the block will be dependent on its mass.

87 Appendix III – Substrate Karma Parameters

Taken from a Screenshot in UnrealEd. It is noted that the final value that was used for the KRestitution Parameter was 0.9, not zero as shown below

88 Appendix IV – Information on the High Speed Video Setup

Calibration object layout. Here, only the x, y points are given. The calibration object

was made in four separate pieces and then assembled for use. The Roman Numerals I-IV

denote the ordering of the pieces. The x, y coordinates given here are given in meters.

The following table gives the camera calibration parameters used by WinAnalyze

Parameter Camera 1 Camera2 Ncx 480 480 Nfx 480 480 dx 0.0074 0.0074 dy 0.0074 0.0074 Cx 278.992 240 Cy 185.007 210 Sx 1.0157 1.0207

89 Appendix V – Karma Parameter Values After Qualitative

Benchmarking

Vehicle Properties

Note: The wheel-leg thickness is 2 Unreal Units, or 0.008 m. The real wheel-leg thickness was 0.00635 m. The difference in thicknes here is due to the resolution available in UnrealEd.

WheelRadius 0.0381 m Dimensions (X, Y, Z) 0.068 m Dimensions (X, Y, Z) 0.09 m Dimensions (X, Y, Z) 0.02 m maxSpinSpeed 30 rad/s bDebug FALSE DrawScale3D (X, Y, Z) 1 DrawScale3D (X, Y, Z) 1 DrawScale3D (X, Y, Z) 1 ChassisMass 0.75 Karma Units MaxTorque 50 Karma Units MotorTorque 50 Karma Units MotorSpeed 0.1745 rad/s SteerPropGap 1000 SteerTorque 1000 Karma Units SteerSpeed 15000

Rear Torsional Stiffness 250 TorsionalStiffness 100 TorsionalDamping 0 DesiredAngle 0

90 Karma Properties KActorGravScale 2.58 KInertiaTensor(0) - Ixx 0.018175 KarmaUnits2 KInertiaTensor(3) - Iyy 0.027974 KarmaUnits2 KInertiaTensor(5) - Izz 0.044637 KarmaUnits2 KCOMOffset (X, Y, Z) 0 KCOMOffset (X, Y, Z) 0 KCOMOffset (X, Y, Z) 0 KLinearDamping 0 KAngularDamping 0 KStartEnabled TRUE bHighDetailOnly FALSE bClientOnly FALSE bKDoubleTickRate TRUE Kfriction 0.9 Name KParams0 KMaxSpeed 10000

Wheel-Leg Properties

Karma Properties KActorGravScale 2.58 bKNonSphericalInertia TRUE KInertiaTensor(0) 0.0035 KarmaUnits2 KInertiaTensor(3) 0.0066 KarmaUnits2 KInertiaTensor(5) 0.0035 KarmaUnits2 KLinearDamping 0 KAngularDamping 0 KMaxAngularSpeed 100 KMaxSpeed 100000 bHighDetailOnly FALSE bClientOnly FALSE bKDoubleTickRate TRUE Kfriction 1 KRestitution 0 Kmass 0.0008 Name KarmaParams0

91 Spacer Plate Properties

Karma Properties KActorGravScale 2.58 bKNonSphericalInertia TRUE KInertiaTensor(0) - Ixx 0 KarmaUnits2 KInertiaTensor(3) - Iyy 0 KarmaUnits2 KInertiaTensor(5) - Izz 0 KarmaUnits2 KLinearDamping 0 KAngularDamping 0 KMaxAngularSpeed 100 KMaxSpeed 100000 bHighDetailOnly FALSE bClientOnly FALSE bKDoubleTickRate TRUE Kfriction Default () KRestitution Default () Kmass 0 Name KarmaParams0

Configuration File Information

To provide an example of what the following “JointParts” entries mean, consider the first entry:

JointParts=(PartName="RightFPlate",PartClass=class'USARModels.JointSpacerPlateTire',DrawS cale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="",JointClass=class'KCarWheelJo

int',ParentPos=(Y=0.057,X=0.03937,Z=0),ParentAxis=(Z=1.0),ParentAxis2=(Y=1.0),SelfPos=(Z=-

0.0),SelfAxis=(Z=1.0),SelfAxis2=(Y=1.0))

• PartName – Used to describe what physical part this item will be on the robot.

This is really to provide a description to the user, and is not actually used by any

of the classes

• PartClass – Tells USARSim which class (and in particular, which static mesh)

should be used to create the part. In this case, the part is a Spacer Plate

92 • DrawScale3D – Tells USARSim how to scale the part in X, Y, and Z. Values of

unity mean that USARSim will use the part at the size at which it was created.

• bSuspensionLocked – This only applies for KCarWheelJoints. It tells USARSim

whether or not to use suspension for the joint.

• KCarWheelJoint – A joint that has a spin axis that is driven by a motor, a steering

axis that is driven by a controlled motor that attempts to achieve a specified

orientation (similar to a servo), and linear suspension

• Parent – Indicates the parent part of PartClass. The part specified by PartClass is

attached to its parent using the specified JointClass. A blank set of double quotes

indicates that the parent is the chassis of the robot, so here, the parent of the

spacer plate is the chassis of the vehicle, and it is connected using a

KCarWheelJoint. As another example, if the parent were a wheel-leg, then the

spacer plate would be connected to the wheel-leg using the KCarWheelJoint.

• JointClass – This is the type of joint that is used to connect the part defined in

PartClass to its parent part.

• ParentPos – Location on the parent part at which the part specified by PartClass is

attached.

• ParentAxis – For a car-wheel joint, it’s the steering axis relative to the parent. For

a hinge joint, it’s the spin axis.

• ParentAxis2 – For a car-wheel joint, it’s the spin axis relative to the parent.

• ParentAxis2 – For a car-wheel joint, it’s the spin axis relative to the parent.

93 • SelfPos – The position where the joint connects the part.

• SelfAxis – For a car-wheel joint, it’s the steering axis relative to the part. For a

hinge joint, it’s the spin axis.

• SelfAxis2 – For a car-wheel joint, it’s the spin axis relative to the part.

All definitions have been taken from, and can be found in the USARSim Manual, which

can be found at [18]. More information on each of the Karma Parameters can be found in

[26, 31] and [31].

Note: Positions in the following table are given in meters.

94

USARBot.Whegs bDebug FALSE Weight 0.175 Payload 2 ChassisMass 0.75 MaxTorque 50 MotorTorque 50 bMountByUU FALSE JointParts=(PartName="RightFPlate",PartClass=class'USARModels.JointSpacerPlateTire',DrawS cale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="",JointClass=class'KCarWheelJo int',ParentPos=(Y=0.057,X=0.03937,Z=0),ParentAxis=(Z=1.0),ParentAxis2=(Y=1.0),SelfPos=(Z=- 0.0),SelfAxis=(Z=1.0),SelfAxis2=(Y=1.0)) JointParts=(PartName="RightFWheel",PartClass=class'USARModels.RightWhegNormalKarma',D rawScale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="RightFPlate",JointClass=cla ss'KDSpringy',ParentPos=(Y=0.011,X=0,Z=0),ParentAxis=(Y=1.0),ParentAxis2=(Z=1.0),SelfPos= (X=0,Y=0,Z=0.0),SelfAxis=(Y=1.0),SelfAxis2=(Z=1.0))

JointParts=(PartName="LeftFPlate",PartClass=class'USARModels.JointSpacerPlateTire',DrawSc ale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="",JointClass=class'KCarWheelJoi nt',ParentPos=(Y=-0.057,X=0.03937,Z=0),ParentAxis=(Z=1.0),ParentAxis2=(Y=1.0),SelfPos=(Z=- 0.0),SelfAxis=(Z=1.0),SelfAxis2=(Y=1.0)) JointParts=(PartName="LeftFWheel",PartClass=class'USARModels.LeftWhegNormalKarma',Dra wScale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="LeftFPlate",JointClass=class' KDSpringy',ParentPos=(Y=- 0.011,X=0,Z=0),ParentAxis=(Y=1.0),ParentAxis2=(Z=1.0),SelfPos=(X=0,Y=0,Z=0.0),SelfAxis=(Y =1.0),SelfAxis2=(Z=1.0))

JointParts=(PartName="RightRPlate",PartClass=class'USARModels.JointSpacerPlateTire',DrawS cale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="",JointClass=class'KCarWheelJo int',ParentPos=(Y=0.05,X=-0.03937,Z=0),ParentAxis=(Z=1.0),ParentAxis2=(Y=1.0),SelfPos=(Z=- 0.0),SelfAxis=(Z=1.0),SelfAxis2=(Y=1.0)) JointParts=(PartName="RightRWheel",PartClass=class'USARModels.LeftWhegNormalKarma',Dr awScale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="RightRPlate",JointClass=cla ss'KDSpringy',ParentPos=(Y=0.0054,X=0,Z=0),ParentAxis=(Y=1.0),ParentAxis2=(Z=1.0),SelfPos =(Z=-0.0),SelfAxis=(Y=1.0),SelfAxis2=(Z=1.0))

JointParts=(PartName="LeftRPlate",PartClass=class'USARModels.JointSpacerPlateTire',DrawSc ale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="",JointClass=class'KCarWheelJoi nt',ParentPos=(Y=-0.05,X=-0.03937,Z=0),ParentAxis=(Z=1.0),ParentAxis2=(Y=1.0),SelfPos=(Z=- 0.0),SelfAxis=(Z=1.0),SelfAxis2=(Y=1.0)) JointParts=(PartName="LeftRWheel",PartClass=class'USARModels.RightWhegNormalKarma',Dr awScale3D=(X=1.0,Y=1.0,Z=1.0),bSuspensionLocked=true,Parent="LeftRPlate",JointClass=clas s'KDSpringy',ParentPos=(Y=- 0.0054,X=0,Z=0),ParentAxis=(Y=1.0),ParentAxis2=(Z=1.0),SelfPos=(Z=- 0.0),SelfAxis=(Y=1.0),SelfAxis2=(Z=1.0))

95 References

[1] L. Southard, T. M. Hoeg, R. Kolacinski, and R. D. Quinn, "Dynamic Simulations

and Control of a Group of Wind Driven Martian Rovers," in

Infotech@Aerospace, AIAA, Washington DC, 2005.

[2] L. Southard, T. M. Hoeg, D. W. Palmer, J. A. A. J. Antol, R. M. A. K. R. M.

Kolacinski, and R. D. A. Q. R. D. Quinn, "Exploring Mars Using a Group of

Tumbleweed Rovers," in Robotics and Automation, 2007 IEEE International

Conference on, 2007, pp. 775-780.

[3] B. Ozdalyan and M. V. Blundell, "Anti-lock braking system simulation and

modelling in ADAMS," in Simulation '98. International Conference on (Conf.

Publ. No. 457), 1998, pp. 140-144.

[4] Q. Donghen, C. Liping, Z. Yifang, and A. X. P. Xiao Pan, "Setting Up and

Simulation of SUV Full Vehicle Handling Stability Based on Multibody

Dynamics," in Mechatronics and Automation, 2007. ICMA 2007. International

Conference on, 2007, pp. 2683-2687.

[5] M. Peasgood, E. Kubica, and J. McPhee, "Stabilization of a Dynamic Walking

Gait Simulation," Journal of Computational and Nonlinear Dynamics, vol. 2, pp.

65-72, 2007.

[6] M. Skelly and H. Chizeck, "Simulation of Bipedal Walking," in Proc. IASTED

International Conference on Applied Modeling and Simulation (AMS 2002),

Cambridge, Massachusetts USA, 2002.

[7] A. S. Boxerbaum, J. Oro, G. Peterson, and R. D. Quinn, "The Latest Generation

of Whegs™ Robots Features a Passive-Compliant Body Joint," in International

96 Conference on Intelligent Robots and Systems (IROS) - Submitted for Review,

2008.

[8] L. R. Palmer and D. E. Orin, "Force Redistribution in a Quadruped Running

Trot," in Robotics and Automation, 2007 IEEE International Conference on,

2007, pp. 4343-4348.

[9] F. Cheli, R. Corradi, G. Diana, and A. Facchinetti, "Validation of a Numerical

Model for the Simulation of Tramcar Vehicle Dynamics by Means of Comparison

With Experimental Data," Journal of Computational and Nonlinear Dynamics,

vol. 2, pp. 299-307, 2007.

[10] M. D. Ford, H. N. Nikolov, J. S. Milner, S. P. Lownie, E. M. DeMont, W. Kalata,

F. Loth, D. W. Holdsworth, and D. A. Steinman, "PIV-Measured Versus CFD-

Predicted Flow Dynamics in Anatomically Realistic Cerebral Aneurysm Models,"

Journal of Biomechanical Engineering, vol. 130, pp. 021015-9, 2008.

[11] T. M. Hoeg, L. Southard, A. S. Boxerbaum, L. Reis, J. A. Antol, J. Heldmann,

and R. D. Quinn, "Tumblewed Rover Science Mission to Dao Vallis," in 44th

AIAA Aerospace Sciences Meeting and Exhibit Reno, NV, 2006.

[12] W. L. Oberkampf, T. G. Trucano, and C. Hirsch, "Verification, validation, and

predictive capability in computational engineering and physics," Applied

Mechanics Reviews, vol. 57, pp. 345-384, 2004.

[13] O. Balci, "Principles and techniques of simulation validation, verification, and

testing," in Simulation Conference Proceedings, 1995. Winter, 1995, pp. 147-154.

[14] MSC Software Products (ADAMS and Visual NASTRAN4D, 5/14, 2008,

http://www.mscsoftware.com/products/?Q=131

97 [15] Design Simulation Technologies - Working Model 2D, 5/18, 2008,

http://www.design-simulation.com/WM2D/index.php

[16] DynaMechs on SourceForge, 5/12, 2008, http://dynamecs.sourceforge.net

[17] RobotBuilder (used with DynaMechs), 5/18, 2008,

http://www.ece.osu.edu/~orin/RobotBuilder/RobotBuilder.html

[18] USARSim on SourceForge, 9/25, 2007, http://sourceforge.net/projects/usarsim

[19] Yobotics Simulation Software, 5/14, 2008,

http://yobotics.com/simulation/simulation.htm

[20] R. T. Schroer, M. J. Boggess, R. J. Bachmann, R. D. Quinn, and R. E. Ritzmann,

"Comparing cockroach and Whegs robot body motions," in Robotics and

Automation, 2004. Proceedings. ICRA '04. 2004 IEEE International Conference

on, 2004, pp. 3288-3293 Vol.4.

[21] R. D. Quinn, G. M. Nelson, R. J. Bachmann, D. A. Kingsley, J. T. Offi, T. J.

Allen, and R. E. Ritzmann, "Parallel Complementary Strategies for Implementing

Biological Principles into Mobile Robots," The International Journal of Robotics

Research, vol. 22, pp. 169-186, March 1, 2003 2003.

[22] S. McMillan, D. E. Orin, and R. B. McGhee, "DynaMechs: An Object Oriented

Software Package for Efficient Dynamic Simulation of Underwater Robotic

Vehicles," in Underwater Robotic Vehicles, Design and Control Alburquerque,

New Mexico USA: TSI Press, 1995, pp. 73-98.

[23] S. Carpin, M. Lewis, W. Jijun, S. A. B. S. Balakirsky, and C. A. S. C. Scrapper,

"USARSim: a robot simulator for research and education," in Robotics and

Automation, 2007 IEEE International Conference on, 2007, pp. 1400-1405.

98 [24] S. Balakirsky, C. Scrapper, C. Carpin, and M. Lewis, "USARSim: Providing a

Framework for Multi-Robot Performance Evaluation," in Performance Metrics

for Intelligent Systems, Gaithersburg, MD USA, 2006.

[25] S. Balakirsky, C. Scrapper, S. Carpin, and M. Lewis, "USARSim: a RoboCup

virtual urban search and rescue competition," in Unmanned Systems Technology

IX, Orlando, FL, USA, 2007, pp. 65611M-11.

[26] Unreal Developer Network, 9/25, 2007,

http://udn.epicgames.com/Main/WebHome.html

[27] C. Pepper, S. Balakirsky, and C. Scrapper, "Robot Simulation Physics

Validation," in Performance Metrics for Intelligent Systems Workshop, NIST

Special Publication 1073, Gaithersburg, MD USA, 2007.

[28] B. K. Taylor, S. Balakirsky, E. Messina, and R. D. Quinn, "Design and Validation

of a Whegs™ Robot in USARSim," in Performance Metrics for Intelligent

Systems Workshop, NIST Special Publication 1073, Gaithersburg, MD USA,

2007.

[29] B. K. Taylor, S. Balakirsky, E. Messina, and R. D. Quinn, "Modeling, validation

and analysis of a Whegs robot in the USARSim environment," in Unmanned

Systems Technology X, Orlando, FL, USA, 2008, pp. 69621B-12.

[30] B. K. Taylor, S. Balakirsky, E. Messina, and R. D. Quinn, "Analysis and

Benchmarking of a Whegs™ Robot in USARSim," in International Conference

on Intelligent Robots and Systems (IROS) - Accpeted, 2008.

99 [31] Unreal Wiki: The Unreal Engine Documentation Site

"http://wiki.beyondunreal.com/wiki/", 2/9, 2008,

http://wiki.beyondunreal.com/wiki/

[32] MOAST on SourceForge, 29/25, 2007, http://sourceforge.net/projects/moast

[33] C. Scrapper, S. Balakirsky, and E. Messina, "MOAST and USARSim: a

combined framework for the development and testing of autonomous systems," in

Unmanned Systems Technology VIII, Orlando (Kissimmee), FL, USA, 2006, pp.

62301T-12.

[34] 2/22, 2008, http://www.isd.mel.nist.gov/US&R_Robot_Standards/index.html

[35] T. J. Allen, R. D. Quinn, R. J. Bachmann, and R. E. Ritzmann, "Abstracted

Biological Principles Applied with reduced Actuation Improve Mobility of

Legged Vehicles," in Intelligent Robots and Systems (IROS). vol. 2, 2003, pp.

1370-1375.

[36] U. Saranli, M. Buehler, and D. E. Koditschek, "RHex: A Simple and Highly

Mobile Hexapod Robot," The International Journal of Robotics Research, vol.

20, pp. 616-631, July 1, 2001 2001.

[37] R. D. Quinn, J. T. Offi, D. A. Kingsley, and R. E. Ritzmann, "Improved mobility

through abstracted biological principles," in Intelligent Robots and System, 2002.

IEEE/RSJ International Conference on, 2002, pp. 2652-2657 vol.3.

[38] K. A. Daltorio, T. C. Witushynsky, G. D. Wile, L. R. Palmer, A. Malek, A. M.

Rasyid, L. Southard, S. N. Gorb, R. E. Ritzmann, and R. D. Quinn, "A Body Joint

Improves Vertical To Horizontal Transitions of a Wall-Climbing Robot," in

100 International Conference on Robotics and Automation (ICRA) Pasadena,

California USA, 2008.

[39] J. M. Morrey, B. Lambrecht, A. D. Horchler, R. E. Ritzmann, and R. D. Quinn,

"Highly mobile and robust small quadruped robots," in Intelligent Robots and

Systems, 2003. (IROS 2003). Proceedings. 2003 IEEE/RSJ International

Conference on, 2003, pp. 82-87 vol.1.

[40] W. A. Lewinger, C. M. Harley, R. E. Ritzmann, M. S. Branicky, and R. D. Quinn,

"Insect-like Antennal Sensing for Climbing and Tunneling Behavior in a

Biologically-inspired Mobile Robot," in Robotics and Automation, 2005. ICRA

2005. Proceedings of the 2005 IEEE International Conference on, 2005, pp.

4176-4181.

[41] W. A. Lewinger, M. S. Watson, and R. D. Quinn, "Obstacle Avoidance Behavior

for a Biologically-inspired Mobile Robot Using Binaural Ultrasonic Sensors," in

Intelligent Robots and Systems, 2006 IEEE/RSJ International Conference on,

2006, pp. 5769-5774.

[42] P. Dunker, W. A. Lewinger, A. Hunt, T. Jacob, J. Caruso, and R. D. Quinn, "A

Biologically Inspired Robot for Lunar Exploration and Regolith Excavation," in

Research ShowCase 2008, Cleveland, OH USA, 2008.

[43] M. Zaratti, M. Fratarcangeli, and L. Iocchi, "A 3D Simulator of Multiple Legged

Robots Based on USARSim," in RoboCup 2006: Robot Soccer World Cup X,

2007, pp. 13-24.

[44] FRAPS, 2/25, 2007, http://www.fraps.com/

101 [45] A. K. Tryba and R. E. Ritzmann, "Multi-Joint Coordination During Walking and

Foothold Searching in the Blaberus Cockroach. I. Kinematics and

Electromyograms," J Neurophysiol, vol. 83, pp. 3323-3336, June 1, 2000 2000.

[46] L. Mu and R. E. Ritzmann, "Kinematics and Motor Activity During Tethered

Walking and Turning in the Cockroach, Blaberus discoidalis," Journal of

Comparative Physiology A: Neuroethology, Sensory, Neural and Behavioral

Physiology, vol. 191, pp. 1037-1054, 2005.

[47] S. N. Fry, R. Sayaman, and M. Dickinson, H., "The Aerodynamics of Free-Fligh

Maneuvers in Drosophila," Science, vol. 300, pp. 495-498, 2003.

[48] J. Herberholz, M. Sen, and D. Edwards, "Escape Behavior and Escape Circuit

Activation in Juvenile Crayfish During Prey-Predator Interactions," Journal of

Experimental Biology, vol. 207, pp. 1855-1863, 2004.

[49] Winanalyzie Automatic Motion Analysis Software Reference Manual.

[50] J. J. Craig, Introduction to Robotics, Mechanics, and Control, 2 ed.: Addison-

Wesley Publishing Company, 1989.

[51] R. J. Bachmann, F. J. Boria, P. Ifju, G., R. D. Quinn, J. E. Kline, and R.

Vaidyanathan, "Utility of a Sensor Platform Capable of Aerial and Terrestrial

Locomotion," in Advanced Intelligent Mechatronics Montery, California USA,

2005, pp. 1581-1586.

[52] F. J. Boria, R. J. Bachmann, P. G. Ifju, R. D. Quinn, R. Vaidyanathan, C. Perry,

and J. Wagener, "A sensor platform capable of aerial and terrestrial locomotion,"

in Intelligent Robots and Systems, 2005. (IROS 2005). 2005 IEEE/RSJ

International Conference on, 2005, pp. 3959-3964.

102