Chetan Kapoor Dissertation

8/3/2019 Chetan Kapoor Dissertation

http://slidepdf.com/reader/full/chetan-kapoor-dissertation 1/612

Copyright

by

Chetan Kapoor

1996



A Reusable Operational Software Architecture for

Advanced Robotics

by

Chetan Kapoor, M.S.

Dissertation

Presented to the Faculty of the Graduate School of

the University of Texas at Austin

in Partial Fulfillment

of the Requirements

for the Degree of

Doctor of Philosophy

The University of Texas at Austin

December, 1996




Advanced Robotics

Approved by

Dissertation Committee:



To my Parents

Subhash Kapoor and Rewa Kapoor



v

Acknowledgments

This work was partially funded by the U.S. Department of Energy (Grant

No. DE-FG01-94EW37966), and NASA (Grant No. NAG 9-809). This research

would not have been possible without the constant guidance, help, and support of

Dr. Delbert Tesar, my committee chairman and academic advisor. I would also

like to thank my committee members Dr. Rich Hooper, Dr. James Browne, Dr.

S.V. Sreenivasan, Dr. Dan Cox, and Dr. Richard Crawford, who’s time and help

is very much appreciated.

I would also like to thank Kevin Rackers for testing the software andCarsten Puls for offering useful suggestions regarding the writing of this report.

Thanks are due to Murat Cetin, Mitch Pryor, Troy Harden, Jorge Ruiz, Chris

Cocca, Andy Legoullen, and Dr. Rich Hooper for evaluating this research.

Finally, I owe a lot to my family and friends who have brought me to this

denouement. This research would be incomplete without a mention of their

sacrifice and support.



vi


Advanced Robotics

Publication No. ________________

Chetan Kapoor, Ph.D.

The University of Texas at Austin, 1996

Supervisor: Delbert Tesar

Robotic software can be broadly categorized into two levels. The first is

the actuator control software. The other level is the system control software.

Three layers further comprise the system control software. The top-most is the

man-machine interface. The lowest is the real-time control layer. The middlelayer is known as the operational software layer.

Current industrial robots are monolithic six degrees-of-freedom

manipulators that have minimal operational software requirements. On the other

hand, advanced robots are based on modularity, redundancy, fault-tolerance, and

performance. The operational software layer for these robots should be general

and reconfigurable, and should support kinematics, dynamics, deflection

modeling, performance criteria, fault-tolerance, and condition-based maintenance.

The development of a reusable and general architecture for the operational

software layer is the prime goal of this research. This includes:

• requirements generation for an advanced robotic software system,



vii

• the selection of a development, execution, and test environment,

•

the development of a reusable software architecture to support OperationalSoftware Components for Advanced Robots (OSCAR),

• the development of applications to demonstrate OSCAR in simulation on a

wide variety of robots and in real-time on a seventeen degrees-of-freedom

dual-arm manipulator,

• the design and development of experiments to validate the advantages of

OSCAR,

• development and demonstration of a real-time formulation of the direct-search

generalized inverse kinematics scheme.

The development of OSCAR is based on object-oriented design. Object-

oriented design professes the development of software components that are

extensible and have standardized interfaces. The application of this philosophy

led to the break-down of the advanced robotics domain into sub-domains. An

analysis of these sub-domains lead to the identification of components that made

up the sub-domain. A detailed analysis and design of these components then

followed.

Applications and experimentation validated the effectiveness of this

software architecture. Achieved goals of this software architecture were

demonstrated by the applications. The experiments demonstrated that OSCAR

provided a 30% improvement in its ‘ease of use’ and an approximately 200%

reduction in program development time as compared to the other robotic software

in use at the Robotics Research Group.

The real-time formulation of the direct-search inverse kinematics

technique showed a 170-times performance improvement when used on a seven

degrees-of-freedom robot.



viii

Table of Contents

LIST OF TABLES ................................................................................................................. .... xvii

LIST OF FIGURES ................................................................................................................ ......xx

NOMENCLATURE...................................................................................................................xxiv

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

1.1. THE THREE LAYERS OF A ROBOTIC SOFTWARE SYSTEM........................................................21.2. RESEARCH OBJECTIVES .........................................................................................................41.3. MODULAR ROBOTICS.............................................................................................................61.4. ROBOT CONTROL ...................................................................................................................71.5. GENERALIZED KINEMATICS ...................................................................................................81.6. GENERALIZED DYNAMICS ......................................................................................................91.7. DEFLECTION MODELING ......................................................................................................101.8. FAULT-TOLERANCE .............................................................................................................111.9. DECISION MAKING...............................................................................................................121.10. OVERVIEW .........................................................................................................................14

CHAPTER TWO LITERATURE REVIEW.............................................................................17

2.1. INTRODUCTION ....................................................................................................................172.2. MECHANICAL HARDWARE ...................................................................................................20

2.2.1. Modularity and Reconfigurability ...............................................................................21

2.2.2. Redundancy and Fault-Tolerance ...............................................................................25

2.2.3. Precision......................................................................................................................26

2.2.4. Maintainability ............................................................................................................27

2.3. COMPUTER HARDWARE .......................................................................................................292.3.1. Servo-Level Hardware.................................................................................................30

2.3.1.1. Centralized Control ............................................................................................................312.3.1.2. Distributed Control .............................................................................................................32

2.3.2. System Controller Hardware.......................................................................................33

2.3.3. Computer Bus ..............................................................................................................35

2.4. SOFTWARE ...........................................................................................................................372.5. SOFTWARE TECHNOLOGY ....................................................................................................40

2.5.1. Software Design...........................................................................................................412.5.1.1. Structured Design...............................................................................................................412.5.1.2. Object-Oriented Design......................................................................................................42

2.5.1.2.1. Classes........................................................................................................................ 432.5.1.2.2. Data Abstraction.........................................................................................................462.5.1.2.3. Inheritance..................................................................................................................47

2.5.1.2.4. Polymorphism ............................................................................................................492.5.1.2.5. Dynamic Binding .......................................................................................................492.5.1.3. Object Oriented Support for Good Design .........................................................................50

2.5.2. Real-Time Software .....................................................................................................532.5.2.1. Ad Hoc Approach...............................................................................................................532.5.2.2. Multitasking Approach.......................................................................................................552.5.2.3. Real-Time Operating Systems ............................................................................................56

2.6. ROBOTIC SOFTWARE SYSTEMS ............................................................................................58



ix

2.6.1. Man-Machine Interface ............ ............ ............ ............ ............. ............ ............ ..........58

2.6.2. Operational Software ..................................................................................................592.6.2.1. RCCL (Robot Control C Libraries) ....................................................................................602.6.2.2. Robot Independent Programming Environment (RIPE).....................................................612.6.2.3. Generic Intelligent System Control (GISC)........................................................................612.6.2.4. Sequential Modular Architecture for Robotics and Teleoperation .....................................622.6.2.5. Control Shell ......................................................................................................................632.6.2.6. Robot Shell.........................................................................................................................642.6.2.7. Design Automation.............................................................................................................642.6.2.8. Various Object-Oriented Robotic Environments................................................................662.6.2.9. Summary of the Operational Software Literature Review..................................................68

2.6.3. Real-time Layer ...........................................................................................................70

2.7. IMPACT OF ADVANCEMENT IN COMPUTER TECHNOLOGY....................................................712.8. DESIRED CHARACTERISTICS OF THE SOFTWARE SYSTEM .....................................................722.9. GENERALIZED KINEMATICS .................................................................................................75

2.9.1. Direct-Search Formulation .........................................................................................76

2.10. SUMMARY..........................................................................................................................77CHAPTER THREE PERFORMANCE-BASED HYBRID GENERALIZED INVERSE .....80

3.1. INTRODUCTION ....................................................................................................................803.2. INVERSE KINEMATICS ..........................................................................................................803.3. DIRECT SEARCH TECHNIQUE ...............................................................................................83

3.3.1. Strengths......................................................................................................................89

3.3.2. Weaknesses..................................................................................................................89

3.4. HYBRID FORMULATION........................................................................................................903.4.1. Generalized Inverse Scheme........................................................................................92

3.4.2. Options Ranking..........................................................................................................96

3.5. EXAMPLE OF HYBRID GENERALIZED INVERSE ...................................................................1013.5.1. Example Performance Criteria..................................................................................102

3.5.2. Example Results.........................................................................................................1033.5.3. Performance Comparison with Hooper’s [1994] Scheme ........................................108

3.6. SUMMARY..........................................................................................................................110

CHAPTER FOUR DEVELOPMENT, EXECUTION, AND TEST ENVIRONMENT.......111

4.1. DEVELOPMENT AND EXECUTION ENVIRONMENT TYPES ....................................................1124.1.1. Self-Hosted Systems...................................................................................................112

4.1.2. Cross-Development Systems......................................................................................114

4.2. DEVELOPMENT ENVIRONMENT SELECTION........................................................................1154.2.1. Software Design Methodology...................................................................................116

4.2.2. Language Selection ...................................................................................................117

4.2.3. Operating System Selection .......................................................................................119

4.3. EXECUTION ENVIRONMENT SELECTION .............................................................................121

4.3.1. Operating System Selection ............ ............ ............ ............ ............. ............ ............ ..1224.3.2. Execution Computer Hardware.................................................................................1254.3.2.1. Processor ............................................................................................................. .............1264.3.2.2. Bus Type...........................................................................................................................128

4.4. SUMMARY OF THE SELECTED ENVIRONMENT ....................................................................1314.5. TEST ENVIRONMENT CHARACTERISTICS............................................................................1334.6. HARDWARE DESCRIPTION ..................................................................................................143



x

4.7. ORGANIZATIONAL AND MANAGERIAL ISSUES ....................................................................1544.8. SUMMARY..........................................................................................................................155

1. INTRODUCTION .................................................................................................................1

1.1. THE THREE LAYERS OF A ROBOTIC SOFTWARE SYSTEM .....................................................21.2. RESEARCH OBJECTIVES .......................................................................................................41.3. MODULAR ROBOTICS...........................................................................................................61.4. ROBOT CONTROL.................................................................................................................71.5. GENERALIZED KINEMATICS .................................................................................................81.6. GENERALIZED DYNAMICS ...................................................................................................91.7. DEFLECTION MODELING ....................................................................................................101.8. FAULT-TOLERANCE ...........................................................................................................111.9. DECISION MAKING.............................................................................................................121.10. OVERVIEW....................................................................................................................14

2. LITERATURE REVIEW ...................................................................................................17

2.1. INTRODUCTION..................................................................................................................172.2. MECHANICAL HARDWARE.................................................................................................20

2.2.1. Modularity and Reconfigurability...........................................................................21

2.2.2. Redundancy and Fault-Tolerance...........................................................................25

2.2.3. Precision .................................................................................................................26

2.2.4. Maintainability........................................................................................................27

2.3. COMPUTER HARDWARE.....................................................................................................292.3.1. Servo-Level Hardware ............................................................................................30

2.3.1.1. ..................................................................................................Centralized Control31

2.3.1.2. ..................................................................................................Distributed Control32

2.3.2. System Controller Hardware...................................................................................332.3.3. Computer Bus..........................................................................................................35

2.4. SOFTWARE.........................................................................................................................372.5. SOFTWARE TECHNOLOGY..................................................................................................40

2.5.1. Software Design ......................................................................................................412.5.1.1. .................................................................................................... Structured Design41

2.5.1.2. ........................................................................................... Object-Oriented Design42

2.5.1.2.1..............................................................................................................Classes43

2.5.1.2.2............................................................................................... Data Abstraction46

2.5.1.2.3........................................................................................................ Inheritance47

2.5.1.2.4...................................................................................................Polymorphism49

2.5.1.2.5..............................................................................................Dynamic Binding49

2.5.1.3. .............................................................. Object Oriented Support for Good Design50

2.5.2. Real-Time Software.................................................................................................532.5.2.1. ....................................................................................................Ad Hoc Approach53

2.5.2.2. ............................................................................................ Multitasking Approach55



xi

2.5.2.3. ................................................................................. Real-Time Operating Systems56

2.6. ROBOTIC SOFTWARE SYSTEMS ..........................................................................................58

2.6.1. Man-Machine Interface...........................................................................................582.6.2. Operational Software ..............................................................................................59

2.6.2.1. ......................................................................... RCCL (Robot Control C Libraries)60

2.6.2.2. .......................................... Robot Independent Programming Environment (RIPE)61

2.6.2.3. ............................................................. Generic Intelligent System Control (GISC)61

2.6.2.4. .......................... Sequential Modular Architecture for Robotics and Teleoperation62

2.6.2.5. ............................................................................................................Control She ll63

2.6.2.6. .............................................................................................................. Robot Shell 64

2.6.2.7. ..................................................................................................Design Automation64

2.6.2.8......................................................Various Object-Oriented Robotic Environments66

2.6.2.9. ....................................... Summary of the Operational Software Literature Review68

2.6.3. Real-time Layer.......................................................................................................70

2.7. IMPACT OF ADVANCEMENT IN COMPUTER TECHNOLOGY..................................................712.8. DESIRED CHARACTERISTICS OF THE SOFTWARE SYSTEM ..................................................722.9. GENERALIZED KINEMATICS ...............................................................................................75

2.9.1. Direct-Search Formulation.....................................................................................76

2.10. SUMMARY ....................................................................................................................77

3. PERFORMANCE-BASED HYBRID GENERALIZED INVERSE................................80

3.1. INTRODUCTION..................................................................................................................803.2. INVERSE KINEMATICS........................................................................................................803.3. DIRECT SEARCH TECHNIQUE .............................................................................................83

3.3.1. Strengths..................................................................................................................89

3.3.2. Weaknesses..............................................................................................................893.4. HYBRID FORMULATION .....................................................................................................90

3.4.1. Generalized Inverse Scheme ...................................................................................92

3.4.2. Options Ranking......................................................................................................96

3.5. EXAMPLE OF HYBRID GENERALIZED INVERSE.................................................................1013.5.1. Example Performance Criteria .............................................................................102

3.5.2. Example Results ....................................................................................................103

3.5.3. Performance Comparison with Hooper’s [1994] Scheme....................................108

3.6. SUMMARY .......................................................................................................................110

4. DEVELOPMENT, EXECUTION, AND TEST ENVIRONMENT...............................111

4.1. DEVELOPMENT AND EXECUTION ENVIRONMENT TYPES..................................................1124.1.1. Self-Hosted Systems ..............................................................................................112

4.1.2. Cross-Development Systems..................................................................................1144.2. DEVELOPMENT ENVIRONMENT SELECTION .....................................................................115

4.2.1. Software Design Methodology ..............................................................................116

4.2.2. Language Selection ...............................................................................................117

4.2.3. Operating System Selection...................................................................................119

4.3. EXECUTION ENVIRONMENT SELECTION ...........................................................................1214.3.1. Operating System Selection...................................................................................122



xii

4.3.2. Execution Computer Hardware ............................................................................1254.3.2.1...................................................................................................................Processor126

4.3.2.2. ..................................................................................................................Bus Type128

4.4. SUMMARY OF THE SELECTED ENVIRONMENT ..................................................................1314.5. TEST ENVIRONMENT CHARACTERISTICS..........................................................................1334.6. HARDWARE DESCRIPTION ...............................................................................................1434.7. ORGANIZATIONAL AND MANAGERIAL ISSUES ..................................................................1544.8. SUMMARY .......................................................................................................................155



xiii

APPENDIX A SOFTWARE DEVELOPMENT GUIDELINES............................................369

A.1. SOFTWARE DESIGN PHILOSOPHY.......................................................................................369

A.2. HOW DO WE ACHIEVE OUR DESIGN GOALS? .......................................................................370A.3. THE DESIGN PROCESS .......................................................................................................371A.4. TRADITIONAL ENGINEERING DESIGN.................................................................................372

A.4.1. What is Design? ........................................................................................................372

A.4.2. What are the qualities of a good designer?...............................................................372

A.4.3. Summary of the Design Process................................................................................372

A.4.4. Critical Path Analysis ...............................................................................................373

A.5. SOFTWARE DESIGN PROCESS ............................................................................................373 A.5.1. Requirement Analysis................................................................................................373

A.5.2. Domain Analysis .......................................................................................................373

A.5.3. System Design ...........................................................................................................374

A.6. PROGRAMMING GUIDELINES .............................................................................................375A.7. EXAMPLE ..........................................................................................................................376

A.7.1. File Vector.hpp..........................................................................................................376 A.7.2. File Vector.ipp ..........................................................................................................378

A.7.3. File Vector.cpp..........................................................................................................381

APPENDIX B OSCAR CLASS LIBRARY REFERENCE....................................................384

B.1. BASE ABSTRACTIONS........................................................................................................384 B.1.1. class RRBase.............................................................................................................384

B.2. MATHEMATICAL ABSTRACTIONS.......................................................................................386 B.2.1. class RRVector : public RRBase ..............................................................................386

B.2.2. Class RRVector3 : public RRVector........ .......... ........... .......... ........... .......... ........... ..391

B.2.3. Class RRHandPose : public RRVector......... ........... .......... ........... .......... ........... .......394

B.2.4. Class RRMatrix : public RRBase .............................................................................398

B.2.5. Class RRMatrixCol : public RRBase.......... .......... ........... ........... .......... ........... .........404

B.2.6. Class RRMatrixCol : public RRBase.......... .......... ........... ........... .......... ........... .........405 B.2.7. Class RRXform : public RRMatrix...........................................................................406

B.2.8. Class RRRot3by3 : public RRMatrix..... .......... ........... ........... .......... ........... .......... ....409

B.2.9. Class RRTensor : public RRMatrix..........................................................................412

B.3. ROBOT DATA ABSTRACTIONS ...........................................................................................414 B.3.1. class RRRobotData : public RRBase .......................................................................414

B.3.2. class RRMatrixData : public RRBase ......................................................................415

B.3.3. class RRTensorData : public RRBase.......... ........... .......... ........... .......... ........... .......417

B.3.4. class RRDHData : public RRBase ...........................................................................419

B.4. FORWARD KINEMATICS ABSTRACTIONS............................................................................421 B.4.1. class RRFKPosition : public RRBase......... ........... .......... ........... .......... ........... .........421

B.4.2. class RRFKJacobian : public RRFKPosition............. ........... .......... ........... .......... ....426

B.4.3. class RRFKPartialJacobian : public RRFKJacobian ......... ......... ......... .......... .........428

B.4.4. class RRFKVelocity : public RRFKJacobian.......... ........... .......... ........... .......... .......431 B.4.5. class RRFKAcceleration : public RRFKVelocity .......... .......... ........... .......... ........... .433

B.5. INVERSE KINEMATICS ABSTRACTIONS ..............................................................................436 B.5.1. class RRIKPosition : public RRBase..... .......... ........... ........... .......... ........... .......... ....436

B.5.2. class RRIKVelocity : public RRIKPosition ..............................................................438

B.5.3. class RRIKJacobian : public RRIKVelocity .......... .......... ........... .......... ........... .........439

B.5.4. class RRIKJForSix : public RRIKJacobian .............................................................443



xiv

B.5.5. class RRIKJForGTSix : public RRIKJacobian ........................................................445

B.5.6. class RRIKJPartial : public RRIKJacobian .......... .......... ........... .......... ........... .........447

B.6. PERFORMANCE CRITERIA ABSTRACTIONS.........................................................................450 B.6.1. class RRPerformanceCriteria : public RRBase .......................................................450

B.6.2. class RRPCAvoidLimits : public RRPerformanceCriteria ........ .......... ......... ......... ...453

B.6.3. class RRPCMinimizeVelocity : public RRPerformanceCriteria .......... ........... .........456

B.6.4. class RRPCMaximizeMOM : public RRPerformanceCriteria ......... ........... .......... ...458

B.6.5. class RRPCFusion : public RRBase............. .......... ........... .......... ........... .......... ........460

B.7. INVERSE DYNAMICS ABSTRACTIONS.................................................................................463 B.7.1. class RRInverseDynamics : public RRBase .............................................................463

B.7.2. class RRIDNewtonEuler : public RRInverseDynamics.hpp .......... ........... .......... ......465

B.7.3. class RRIDLagrange : public RRInverseDynamics.hpp ..........................................467

B.8. DEFLECTION MODELING ABSTRACTIONS...........................................................................474 B.8.1. class RRDeflection : public RRBase ........................................................................474

B.9. IODEVICES ABSTRACTIONS...............................................................................................477 B.9.1. class RRKeyboard : public RRBase .........................................................................477

B.10. CONTROLLER ABSTRACTIONS .........................................................................................479 B.10.1. class RRController : public RRBase ......................................................................479

B.10.2. class RRTeachBall : public RRController...... .......... ........... .......... ........... .......... ....480

B.11. UTILITY ABSTRACTIONS..................................................................................................483 B.11.1. class RRTimer : public RRBase .............................................................................483

B.12. COMMUNICATIONS ABSTRACTIONS.................................................................................484 B.12.1. class RRTCP : public RRBase...... .......... ........... ........... .......... ........... .......... ...........484

B.12.2. class RRTCPClient : public RRTCP ......................................................................485

B.12.3. class RRTCPServer : public RRTCP............ ........... .......... ........... .......... ........... .....486

APPENDIX C EXPERIMENTS WITH OSCAR....................................................................487

C.1. PROPOSED TEST ACTIVITY ................................................................................................487C.2. DESIRED USER QUALIFICATIONS .......................................................................................488C.3. SOFTWARE DEVELOPMENT ENVIRONMENT .......................................................................489

C.3.1. Programming Language...........................................................................................489

C.3.2. Operating Systems ....................................................................................................490

C.3.3. Source Code Organization........................................................................................490

C.3.4. Source Code Management........................................................................................493

C.4. PROGRAM EXECUTION ENVIRONMENT..............................................................................493C.5. EXPERIMENTAL ACTIVITY .................................................................................................494

C.5.1. Experiment 1 .............................................................................................................496

C.5.2. Experiment 2 .............................................................................................................497

C.5.3. Experiment 3 .............................................................................................................498

C.5.4. Experiment 4 .............................................................................................................499

C.5.5. Experiment 5 .............................................................................................................500

C.5.6. Experiment 6 .............................................................................................................501

C.5.7. Experiment 7 .............................................................................................................502

C.5.8. Experiment 8 .............................................................................................................504

C.5.9. Experiment 9 .............................................................................................................505

C.5.10. Experiment 10 .........................................................................................................507

C.6. USER QUALIFICATION ASSESSMENT ..................................................................................508C.7. EXPERIMENT RESULTS ......................................................................................................509



xv

C.7.1. Experimenter A .........................................................................................................509

C.7.2. Experimenter B .........................................................................................................512

C.7.3. Experimenter C .........................................................................................................517

C.7.4. Experimenter D.........................................................................................................521

C.7.5. Experimenter E .........................................................................................................524

C.7.6. Experimenter F .........................................................................................................530

C.7.7. Experimenter G.........................................................................................................534

C.7.8. Experimenter H.........................................................................................................535

APPENDIX D CLASS LIBRARIES FOR 3D PROCEDURAL MODELING .....................541

D.1. INTRODUCTION..................................................................................................................541D.2. MATHEMATICAL CLASSES .................................................................................................542

D.2.1. Class Matrix..............................................................................................................542

D.2.2. Class TransformMatrix : public Matrix......... ........... .......... ........... .......... ........... .....542

D.2.3. Class Vector..............................................................................................................542

D.2.4. Class Tensor .............................................................................................................543

D.3. GEOMETRY RELATED CLASSES .........................................................................................543 D.3.1. Class Point................................................................................................................543

D.3.2. Class Vector3D : public Vector...............................................................................543

D.3.3. Class Polygon ...........................................................................................................544

D.3.4. Class Attributes.........................................................................................................545

D.3.5. Class Shape...............................................................................................................545

D.3.6. Class QuadMeshShape : public Shape....................................................................545

D.3.7. Class TriMeshShape : public Shape........................................................................546

D.3.8. Class PolyShape : public Shape ..............................................................................546

D.3.9. Class Cylinder : public QuadMeshShape................................................................546

D.3.10. Class CylinderX : public Cylinder........... .......... ........... .......... ........... .......... ..........546

D.3.11. Class CylinderY : public Cylinder.........................................................................546

D.3.12. Class CylinderZ : public Cylinder.........................................................................546

D.3.13. Class TruncCone : public QuadMeshShape ......... ......... .......... ......... ......... .......... ..547

D.3.14. Class TruncConeX : public TruncCone............ .......... ........... .......... ........... .......... .547

D.3.15. Class TruncConeY : public TruncCone ......... ........... .......... ........... ........... .......... ...547

D.3.16. Class TruncConeZ : public TruncCone ......... ........... .......... ........... ........... .......... ...547

D.3.17. Class Extrusion : public QuadMeshShape ............................................................547

D.3.18. Class Sweep : public QuadMeshShape..... ......... ......... .......... ......... ......... .......... .....549

D.3.19. Class Cone : public TriMeshShape .......................................................................550

D.3.20. Class ConeX : public Cone............. ........... .......... ........... .......... ........... ........... .......550

D.3.21. Class ConeY : public Cone ....................................................................................550

D.3.22. Class ConeZ : public Cone ....................................................................................550

D.3.23. Class Disk : public TriMeshShape....... ........... .......... ........... .......... ........... .......... ...550

D.3.24. Class DiskX : public Disk ......................................................................................550

D.3.25. Class DiskY : public Disk ......................................................................................551

D.3.26. Class DiskZ : public Disk ......................................................................................551

D.3.27. Class Box : public PolyShape............. ........... .......... ........... .......... ........... .......... ....551

D.4. CLASS DIAGRAMS .............................................................................................................551D.5. HEADER FILES...................................................................................................................556

D.5.1. Rmath.h - Matrix, TransformMatrix, Vector, and Tensor.........................................556

D.5.2. Draw.h - Point and Vector3D class..........................................................................561



xvi

D.5.3. Shape.h - Polygon and Derivations of the Shape class ......... .......... ......... ......... .......563

D.5.4. Environment.h - Material, Environment, and Light .................................................570

D.5.5. Defines.h: Material and Color Declarations.......... .......... ........... .......... ........... .......574

REFERENCES............................................................................................................................575

VITA ............................................................................................................................................588



xvii

List of Tables

Table 2.1: Impact of Mechanical Hardware on Software Requirements. ............ 29

Table 2.2: Impact of Control Hardware on Software Requirements.................... 37

Table 2.3: Listing of Required Software Modules. .............................................. 40

Table 2.4: Summary of Robotic Software Systems. ............................................ 69

Table 3.1: Operational Characteristics of the Example Application of the Hybrid

Scheme. ............................................................................................................... 109

Table 4.1: Comparative Analysis of Reviewed Programming Languages......... 118

Table 4.2: UNIX Workstations Considered for Software Development............121

Table 4.3: Commercially Available Real-Time Operating Systems.................. 125

Table 4.4: Benchmarks for Various Processors. ................................................ 127

Table 4.5: Overview of Some Commercially Available Buses.......................... 130

Table 4.6: Summary of Selected Systems.......................................................... 132

Table 4.7: SUN SPARC 20-61 Specifications................................................... 144

Table 4.8: Dell Personal Computer Specifications. ........................................... 145

Table 4.9: VME Bus Specifications................................................................... 145

Table 4.10: Force CPU 30 Card Specifications. ................................................ 147

Table 4.11: Bit 3 VME to Multibus Adapter Specifications.............................. 147

Table 4.12: Silicon Graphics Specifications. ..................................................... 152

TABLE 2.1: IMPACT OF MECHANICAL HARDWARE ON SOFTWARE

REQUIREMENTS........................................................................................................................29

TABLE 2.2: IMPACT OF CONTROL HARDWARE ON SOFTWARE REQUIREMENTS.37



xviii

TABLE 2.3: LISTING OF REQUIRED SOFTWARE MODULES........................................40

TABLE 2.4: SUMMARY OF ROBOTIC SOFTWARE SYSTEMS.......................................69

TABLE 3.1: OPERATIONAL CHARACTERISTICS OF THE EXAMPLE APPLICATION

OF THE HYBRID SCHEME. ...................................................................................................109

TABLE 4.1: COMPARATIVE ANALYSIS OF REVIEWED PROGRAMMING

LANGUAGES. ............................................................................................................................118

TABLE 4.2: UNIX WORKSTATIONS CONSIDERED FOR SOFTWARE

DEVELOPMENT. ......................................................................................................................121

TABLE 4.3: COMMERCIALLY AVAILABLE REAL-TIME OPERATING SYSTEMS.125

TABLE 4.4: BENCHMARKS FOR VARIOUS PROCESSORS...........................................127

TABLE 4.5: OVERVIEW OF SOME COMMERCIALLY AVAILABLE BUSES.............130

TABLE 4.6: SUMMARY OF SELECTED SYSTEMS. .........................................................132

TABLE 4.7: SUN SPARC 20-61 SPECIFICATIONS.............................................................144

TABLE 4.8: DELL PERSONAL COMPUTER SPECIFICATIONS....................................145

TABLE 4.9: VME BUS SPECIFICATIONS...........................................................................145

TABLE 4.10: FORCE CPU 30 CARD SPECIFICATIONS...................................................147

TABLE 4.11: BIT 3 VME TO MULTIBUS ADAPTER SPECIFICATIONS......................147

TABLE 4.12: SILICON GRAPHICS SPECIFICATIONS.....................................................152

Table C.1: Evaluation Sheet for Experiments with OSCAR. ............................ 495



xix

List of Figures

Figure 1.1: The Three Layers of Robotic Software................................................ 4

Figure 2.1: The I-STAR Environment for System Design................................... 19

Figure 2.2: A Six DOF Monolithic Robot. .......................................................... 22

Figure 2.3: A Six DOF Modular Robot. .............................................................. 23

Figure 2.4: Exploded View of the Modular Robot. ............................................. 24

Figure 2.5: A Ten DOF Fault-Tolerant Manipulator. .......................................... 25

Figure 2.6: Centralized Control Structure [Puls, 1994]. ...................................... 31

Figure 2.7: Distributed Control Structure [Puls, 1994]........................................ 32

Figure 2.8: Structured Program Design................................................................ 42

Figure 2.9: Abstract Data Type Matrix. ............................................................... 47

Figure 2.10: Matrix Class Inheritance.................................................................. 48

Figure 2.11: Ad hoc Style of Real-Time Software Design. ................................. 54

Figure 2.12: Task-Based Real-Time Software Design......................................... 56

Figure 2.13: Desired Functionality of the Operational Software Layer. .............. 74

Figure 3.1: A Three DOF Planar Robot. .............................................................. 81

Figure 3.2: A Hypercube Representing the Explorations for a Three DOF Robot[Hooper, 1994]. ..................................................................................................... 86

Figure 3.3: Self-Motion of a Redundant Arm...................................................... 87

Figure 3.4: Inverse Kinematics Using Direct-Search and a Closed-Form InversePosition Solution. .................................................................................................. 88

Figure 3.5: Hybrid Formulation for Generalized Inverse..................................... 91

Figure 3.5: Single Criterion Optimization. .......................................................... 97



xx

Figure 3.6: An Example of Criteria Fusion.......................................................... 98

Figure 3.7: Ambiguity in Options Selection - Demonstration of Need for CriteriaNormalization........................................................................................................ 99

Figure 3.8: Ambiguity in Options Selection - Need for Variance...................... 100

Figure 3.9: Left Arm During a Section of the Experimental Trajectory............ 103

Figure 3.10: Overall Selected Solution and Best Solution for MOT. ................ 104

Figure 3.11: Overall Selected Solution and Best Solution for JVM. ................. 105

Figure 3.12: Overall Selected Solution and Best Solution for JRA................... 106

Figure 3.13: Variation in Ranking of the Overall Best Solution along the

Trajectory for Individual Criterion...................................................................... 107

Figure 4.1: A Self-Hosted System...................................................................... 113

Figure 4.2: A Cross-development System.......................................................... 114

Figure 4.3: Final Development and Execution Environment............................. 133

Figure 4.4: Multi-user Execution and Test Environment................................... 135

Figure 4.6: Simulation and Physical Robot Support for Testing. ...................... 139

Figure 4.7: Software Development, Execution, and Test Environment............. 142

Figure 4.8: VME Chassis with Plugged in Boards............................................. 146

Figure 4.9: TOS Manual Controller. .................................................................. 148

Figure 4.10: Kraft Manual Controller. ............................................................... 149

Figure 4.11: NASA Perforce Manual Controller. .............................................. 150

Figure 4.12: The TeachBall Input Device. ......................................................... 151

Figure 4.13: The Robotics Research Corporation Dual-Arm Robot.................. 153

Figure 4.14: Future Distributed Environment for Cell Control. ........................ 157



xxi

FIGURE 1.1: THE THREE LAYERS OF ROBOTIC SOFTWARE........................................4

FIGURE 2.1: THE I-STAR ENVIRONMENT FOR SYSTEM DESIGN...............................19

FIGURE 2.2: A SIX DOF MONOLITHIC ROBOT. ...............................................................22

FIGURE 2.3: A SIX DOF MODULAR ROBOT.......................................................................23

FIGURE 2.4: EXPLODED VIEW OF THE MODULAR ROBOT.........................................24

FIGURE 2.5: A TEN DOF FAULT-TOLERANT MANIPULATOR. ....................................25

FIGURE 2.6: CENTRALIZED CONTROL STRUCTURE [PULS, 1994]. ............................31

FIGURE 2.7: DISTRIBUTED CONTROL STRUCTURE [PULS, 1994]. .............................32

FIGURE 2.8: STRUCTURED PROGRAM DESIGN. .............................................................42

FIGURE 2.9: ABSTRACT DATA TYPE MATRIX.................................................................47

FIGURE 2.10: MATRIX CLASS INHERITANCE..................................................................48

FIGURE 2.11: AD HOC STYLE OF REAL-TIME SOFTWARE DESIGN..........................54

FIGURE 2.12: TASK-BASED REAL-TIME SOFTWARE DESIGN.....................................56

FIGURE 2.13: DESIRED FUNCTIONALITY OF THE OPERATIONAL SOFTWARELAYER...........................................................................................................................................74

FIGURE 3.1: A THREE DOF PLANAR ROBOT....................................................................81

FIGURE 3.2: A HYPERCUBE REPRESENTING THE EXPLORATIONS FOR A THREE

DOF ROBOT [HOOPER, 1994]..................................................................................................86

FIGURE 3.3: SELF-MOTION OF A REDUNDANT ARM. ...................................................87

FIGURE 3.4: INVERSE KINEMATICS USING DIRECT-SEARCH AND A CLOSED-

FORM INVERSE POSITION SOLUTION. ..............................................................................88

FIGURE 3.5: HYBRID FORMULATION FOR GENERALIZED INVERSE. .....................91

FIGURE 3.5: SINGLE CRITERION OPTIMIZATION..........................................................97

FIGURE 3.6: AN EXAMPLE OF CRITERIA FUSION..........................................................98



xxii

FIGURE 3.7: AMBIGUITY IN OPTIONS SELECTION - DEMONSTRATION OF NEED

FOR CRITERIA NORMALIZATION.......................................................................................99

FIGURE 3.8: AMBIGUITY IN OPTIONS SELECTION - NEED FOR VARIANCE........100

FIGURE 3.9: LEFT ARM DURING A SECTION OF THE EXPERIMENTAL

TRAJECTORY. ..........................................................................................................................103

FIGURE 3.10: OVERALL SELECTED SOLUTION AND BEST SOLUTION FOR MOT.104

FIGURE 3.11: OVERALL SELECTED SOLUTION AND BEST SOLUTION FOR JVM.105

FIGURE 3.12: OVERALL SELECTED SOLUTION AND BEST SOLUTION FOR JRA.106

FIGURE 3.13: VARIATION IN RANKING OF THE OVERALL BEST SOLUTION

ALONG THE TRAJECTORY FOR INDIVIDUAL CRITERION........................................107

FIGURE 4.1: A SELF-HOSTED SYSTEM.............................................................................113

FIGURE 4.2: A CROSS-DEVELOPMENT SYSTEM. ..........................................................114

FIGURE 4.3: FINAL DEVELOPMENT AND EXECUTION ENVIRONMENT. ..............133

FIGURE 4.4: MULTI-USER EXECUTION AND TEST ENVIRONMENT. ......................135

FIGURE 4.6: SIMULATION AND PHYSICAL ROBOT SUPPORT FOR TESTING. .....139

FIGURE 4.7: SOFTWARE DEVELOPMENT, EXECUTION, AND TEST

ENVIRONMENT........................................................................................................................142

FIGURE 4.8: VME CHASSIS WITH PLUGGED IN BOARDS...........................................146

FIGURE 4.9: TOS MANUAL CONTROLLER......................................................................148

FIGURE 4.10: KRAFT MANUAL CONTROLLER..............................................................149

FIGURE 4.11: NASA PERFORCE MANUAL CONTROLLER. .........................................150

FIGURE 4.12: THE TEACHBALL INPUT DEVICE............................................................151

FIGURE 4.13: THE ROBOTICS RESEARCH CORPORATION DUAL-ARM ROBOT.153

FIGURE 4.14: FUTURE DISTRIBUTED ENVIRONMENT FOR CELL CONTROL......157

Figure C.1: Directory Structure for OSCAR Source Code Organization. ......... 491



xxiii

Figure D.1: Normal Calculation for a Polygon. ................................................. 544

Figure D.2: Coordinate Specification for an I-BEAM Extrusion. ..................... 548

Figure D.3: Class Diagram One. ........................................................................ 552

Figure D.4: Class Diagram Two. ....................................................................... 553

Figure D.5: Class Diagram Three. ..................................................................... 554

Figure D.6: Class Diagram Four. ....................................................................... 555



xxiv

Nomenclature

ADT Abstract Data TypeANSI American National Standards Institute

ASCII American Standard Code for Information InterchangeASME American Society of Mechanical EngineersCAD Computer Aided Design

CPU Central Processing UnitDH Denavit-HartenbergDOF Degree-of-Freedom

GPIB General Purpose Interface BusGUI Graphical User InterfaceI/O Input/Output

IBM International Business Machines CorporationIEEE Institute of Electrical and Electronic EngineersISO Industry Standards Organization

MAX Maximumms millisecond

OS Operating SystemOSCAR Operational Software Components for Advanced RoboticsPC Personal Computer

PID Proportional, Integral, and DerivativePLC Programmable Logic ControlRAM Random Access Memory

RISC Reduced Instruction Set ComputingRPL Robot Programming LanguageRTOS Real Time Operating System

TCP Transmission Control ProtocolOOA Object-oriented AnalysisOOD Object-oriented Design

OOP Object-oriented ProgrammingSVD Singular Value Decomposition



1

Chapter One

1. Introduction

Mechanical systems for manufacturing in the past have represented

monolithic dedicated machines that remained expensive and were inflexible to

product changes due to market demands. Industrial robots, which are key players

in the intelligent machines arena, also exhibit a monolithic mechanical structure

and a closed-system software architecture [Tesar, 1989]. Computer systems by

contrast are increasingly modular, easily upgradable, and rapidly reconfigurable to

meet customer requirements. Robotics research today is focusing on developing

systems that exhibit modularity, flexibility, redundancy, fault-tolerance, a general

and extensible software environment, and seamless connectivity to other

machines.

A modularity-based mechanical structure of machines (robots), coupled

with advancements in computer technology now makes a universal control system

software possible for a very large class of machines. This operating system must

be able to support the development of a full manufacturing cell made up of

fixtures, handling systems, assembly devices, forming sub-systems, etc. The

software architecture for these systems must provide for modularity, software

reuse, rapid-prototyping, and should support generalized kinematics, generalized



2

dynamics, deflection modeling, performance criteria, criteria-fusion, and fault-

tolerance. These are the essential characteristics of an advanced robotics system

and a full implementation of these is necessary to uplift the standard of US

manufacturing, which over the past ten years has seen a $150 billion/year trade

deficit [Tesar, 1994].

1.1. The Three Layers of a Robotic Software System

A robotic software system at the system controller level can be broadly

divided into three layers. The lower-most layer of this system is the hardware-

interface layer. The purpose of this layer is to interface with the servo control

software, peripheral devices, and communication buses. Real-time constraints on

this layer are the most stringent because it interacts with the external hardware. A

parallel software execution environment is best-suited for this layer. This is

because the software in this layer has to handle multiple asynchronous events

(both external and internal) in real-time (less than 1 millisecond).

The top-most layer of a robotic software system is the robot programming

language. This layer provides the man-machine interface. In this layer, programs

written in the robot programming language (RPL) are converted into appropriate

commands for the middle layer. These commands are then translated into

actuator position, velocity and torque commands by the middle layer which are

then sent to the lowest layer.

The middle-layer of the robotic software system is what is referred to

as the operational software layer. Most industrial robots are six degrees-of-

freedom (DOF) arms and have geometries that allow for simple kinematics and

dynamics. As such, their operational software layer is not very demanding and

offers limited capability. For advanced robots, which exhibit reconfigurability,

redundancy, and fault-tolerance, exceptional demands are placed on the



3

operational software. It is desired that this layer of software be robot independent,

reconfigurable if there is a fault, and support software reuse and rapid-

prototyping. Also, the operational software architecture should support

generalized kinematics, generalized dynamics, deflection modeling, performance

criteria, and fault-tolerance in a reusable and modular software architecture. As

this layer relies heavily on compute intensive constructs, it should allow for multi-

processor execution and computational efficiency. Additionally, as most concepts

implemented in this layer are under development, the operational software should

be equally applicable to simulation. This feature allows for algorithm testing

before use on physical hardware. The necessity for compatibility with simulation

is even greater as the operational software architecture being proposed in this

research allows for extensibility and user-modification. The user of this

architecture should be able to test any extensions or modifications to the software

before controlling a physical robot. The three layers of robotic software at the

system controller level are illustrated in Figure 1.1.



4

Graphical User Interface

Robot Programming Language

Generalized Kinematics

Generalized Dynamics

Deflection Modeling

Performance Criteria

Criteria Fusion

Fault-Tolerance

Interface with Servo Controllers

Hardware Interfacing

Real-time Event Handling

Man-Machine Interface

Top-Most Layer

Operational Software

Middle-Layer

Real-Time Control

Lower-Most Layer

Peripheral Equipment

To Simulation

Figure 1.1: The Three Layers of Robotic Software.

1.2. Research Objectives

The middle layer of robotic software, namely, the operational software

layer is the primary focus of this research. Its key goal is to develop an

operational software architecture for intelligent machines. This architecture has

been named “Operational Software Components for Advanced Robotics”

(OSCAR). The desired characteristics of OSCAR are:

1) Support for advanced robotics. Advanced robotics includes

• Redundant robot arms

• Generalized kinematics



5

• Criteria-based decision making

•

Generalized dynamics• Deflection modeling

• Fault-tolerance

2) Completely general software architecture applicable to any serial arm

3) Applicability to real-time control

4) Applicability to simulation

5) Reuse via extensibility

6) Support rapid-prototyping.

7) Reduced control program development time (50% improvement over

previous robotic software architectures in use at the University of Texas

Robotics Research Group).

Besides the key goal of developing an operational software architecture,

with the above characteristics, the other goals that have to be accomplished as a

part of this research are:

• Selection and development of the software development, execution, and test

environment.

• Training of future users of this software architecture.

• Achievement of a practical implementation of Hooper’s [1994] generalized

inverse kinematics scheme.

The development of such an architecture is a challenging task for two

reasons. The first is the inherent complexity of software. The complexity of

software can be attributed to four factors as specified by Booch [1994]. These

are:

• the complexity of the problem domain,

• the difficulty of managing the developmental process,

• the flexibility possible through software, and



6

• the problem of characterizing the behavior of discrete systems.

Additionally, software users often underestimate the complexity of software. This is best illustrated by the fact that a builder rarely asks for the

addition of a basement to an 100 story building. On the other hand, users of

software systems rarely think twice about asking for equivalent changes, arguing

that, it is merely a matter of programming [Booch, 1994].

The second reason that makes the development of an operational software

architecture a challenging task is the complexity of the problem domain, that is,

advanced robotics. Developing a reusable architecture for this domain involves

detailed understanding of all advanced robotic concepts: concepts that are further

based on rigorous mathematical formulations. Also, some of the concepts of

advanced robotics are not fully developed. This adds ambiguity to the problem

domain and limits the reuse potential of the software architecture. Additionally,

the translation of a mathematical formulation (which may be expressed as a

simple equation) may take hundred’s of lines of high-level code.

The following sections in this chapter discuss some of the characteristics

of advanced robotics that this research will address. The last section gives an

overview about what follows in this report.

1.3. Modular Robotics

To achieve a revolution in the manufacturing industry it is crucial to draw

from the successes of the computer industry. The first lesson to learn from the

computer industry is its application of modularity to the design of computers and

especially personal computers. Surprisingly, an intuitive design issue like

modularity is rarely present in the design of industrial robots. Current industrial

robots are monolithic structures that have limited application and almost no



7

upgradability options. On the other hand, a personal computer offers us the best

example of modularity and upgradability. Modularity provides us with a system

that has standardized interfaces and plug-and-play capability. Also, due to the

availability of various modules that maintain standard interfaces, a modular robot

may be configured for a particular task and then quickly reconfigured later if the

task changes. The University of Texas, Robotics Research Group, has been

aggressively pursuing modular robot technology for over two decades [Butler and

Tesar, 1989]. It is the goal of the Robotics Research Group to design a

mechanical architecture that can rapidly evolve in the same fashion as is now

feasible for a personal computer. This effort has centered around the design of a

family of link, joint, and actuator modules. A low-cost prototype modular robot is

currently (July, 1996) under development. This effort is centered on designing

two actuator modules. The larger of the two actuators is used to constitute the

first three joints of the robot and the smaller actuator is used in the wrist of the

robot. Different link geometries can be used to customize this robot for specific

applications [Grupinski, 1996]. In addition, a project to design and build a high

accuracy seven DOF modular robotic system is in its fifth year of development

[Marrs, 1996].

1.4. Robot Control

Once a good mechanical architecture is available for a modular robot, the

next step involves the computer hardware and software concepts for controlling

the robot. Essentially, the control of the robot is at two levels: the servo level and

the system level. The servo level control is used for controlling each individual

actuator and is characterized by a very high update rate (1000 Hertz). In current

industrial robots the servos are located external to the mechanical structure of the

robot arm. This not only leads to a cabling problem, but also destroys the



8

modularity of the system. To solve this problem, the Robotics Research Group at

the University of Texas has developed Digital Intelligent Servo Controller (DISC)

technology [Aalund et al., 1993]. These DISC’s are resident within the robot

structure and are responsible for the low level control of the robot and can run

closed-loop control in position, velocity, and acceleration mode.

The other layer in robot control is composed of the system level controller

whose main purpose is to calculate and transmit position, velocity, or

acceleration-level commands to the servos [Aalund, 1991]. Also, a control loop

(for example, hybrid force control) can be executed at the system level to achieve

desired performance. Besides running the closed loop control, the system level

controller is responsible for solving the robot kinematics and dynamics,

compensate for deflection, enhance performance, and interface with external

equipment. Furthermore, the system controller performs the task of resource

management, responds to external events in real-time, and performs decision

making.

1.5. Generalized Kinematics

Kinematics for robot structures involves computing the forward position

solution, which essentially computes the hand position and orientation based on a

known joint angle set. Kinematics also includes the inverse position solution,

which is used to compute joint angles based on a given hand position and

orientation. Kinematics is usually performed at the position, velocity, and

acceleration-level [Craig, 1986]. One way of computing the forward position

solution is to formulate homogenous transformation matrices for each joint of a

robot. These matrices can then be multiplied to get a description of the position

and orientation of the end-effector of the robot. The homogenous transformation



9

matrices for each joint can be formulated using the Denavit-Hartenberg (DH)

parameters [Craig, 1986].

Position and orientation constraints specify the location of the end-effector

relative to the base of the robot. The inverse kinematics problem is to find the set

of joint displacements satisfying these constraints. A six DOF spatial robot

constitutes a fully motion specified system since there are as many DOF as there

are end-effector specifications (three for position and three for orientation).

Closed-form inverse position solutions are possible for six DOF robots [Craig,

1986]. Numerical solutions are used for redundant robots and they offer the

advantages of generality and reconfiguration [Nakamura, 1993]. A robot with

more DOF than constraints constitutes a redundant robot (an example is a seven

DOF spatial arm). These systems have infinite inverse kinematics solutions

because their Jacobian-based inverse is mathematically non-square. Besides

flexibility, redundancy offers the advantage of incorporation of relevant criteria

that can be used to select a solution that maximizes performance. As advanced

robots are characterized by reconfigurability and redundancy, it is imperative that

the software and algorithm for inverse kinematics be robot independent and

should support criteria-based performance maximization.

1.6. Generalized Dynamics

Along with kinematics, the system controller may calculate the joint

torques required to make the robot end-effector follow a desired trajectory. This

is the inverse dynamics problem and it involves calculating the joint torques based

on a given set of joint positions, velocities, and accelerations. These torques can

be used as signals to be added as feed-forward terms in a conventional feedback

control loop to linearize and decouple the system, thereby improving

performance. This scheme is commonly known as computed torque control



10

[Izaguirre et al., 1992]. Various techniques have been proposed for inverse

dynamics. Of these the most computationally efficient is the Recursive Newton-

Euler [Craig, 1986]. This technique does not provide a description of the system

inertia, and thus cannot be used in mass distribution-based decision making in the

presence of uncertainty. Thomas and Tesar [1982] have proposed a dynamic

modeling technique for serial manipulators that is based on influence coefficients.

Kinematic influence coefficients are based solely on the geometry of the system.

This technique is useful for design as it provides detailed information about the

system behavior and can thus be used for determining load and size of links and

actuators [Thomas and Tesar, 1982]. It also shows all complex terms and can be

used for studying higher-order properties in real-time.

1.7. Deflection Modeling

Another crucial aspect of the system controller, relevant in light machining

operations, is maintaining zero end-effector position and orientation error

[Wander and Tesar, 1992]. This becomes difficult in the presence of end-effector

loads, and joint and link compliance. To counteract this, the load induced

deflection at the end-effector is calculated based on a full compliance model and

the error is then corrected. This involves the knowledge of the robot link and

joint stiffness matrices and accurate geometric dimensions. The work done by

Hudgens [1992] and Knopf [1994] in the area of modular metrology answers

some questions regarding the accurate parameterization of a modular robot. To

calculate the deflection at the end-effector, Fresonke et al. [1988] have proposed a

deflection modeling technique based on kinematic influence coefficients. In this,

the kinematic analysis based on geometric influence coefficients is used to obtain

resultant joint loads. Based on this, the local link deformations are calculated and

the results are combined to get the end-effector deflection [Fresonke et al., 1988].



11

1.8. Fault-Tolerance

After the development of a modular robot architecture, the next step in

robotic research is the meaningful application of this architecture. Tesar and

Butler [1989] outlined some applications that would benefit from the

development of modular robot technology. Space station operation is one of these

applications that involves high cost, a hazardous environment for humans, and

requires almost zero-fault operation. The Robotics Research Group at the

University of Texas at Austin is actively pursuing the application of modular

robotics technology to space station operations with an emphasis on fault-tolerance. Sreevijayan and Tesar [1993] have defined fault-tolerance in a robotics

context as “the capability of a system to sustain a failure and still continue

operation without significant impact on the manipulator payload or its immediate

environment.” They also conceptualized a four-level subsumptive architecture for

fault-tolerant robotics. The level I of this architecture involves duality at the

prime mover level [Iaconics, 1991]. This means that a joint actuator is composed

of two identical sub-systems, where both of these sub-systems are operational

under normal conditions. If there is a fault, one sub-system can take care of the

operational needs minimizing the effects on the total system performance. The

second level of fault-tolerance provides extra joints per DOF of the robot. An

example of this is redundantly actuated parallel structures [Yi, 1992]. The third

level of fault-tolerance encompasses redundant robot arms (more than six joints

for a spatial case) [Hooper, 1994]. In this case, a failure in a joint can still leave

the system with “full” functionality. The fourth level of fault-tolerance involves

multi-arm systems. This is a direct reflection of the anthropomorphic paradigm

[Sreevijayan and Tesar, 1993].



12

As defined by Sreevijayan and Tesar [1993], Level III fault-tolerance

entails the presence of redundancy in the number of joints of a robot arm. The

requirement here is that a robot arm should be able to maintain dexterity and full

access to its workspace if there is a joint failure. This is achieved by imparting

the robot with more DOF than would be required (greater than six in the case of a

spatial robot) [Hooper, 1994]. However, the presence of extra DOF leads to a

non-square system that has infinite solutions. Thus, for any given hand position

and orientation, there are an infinite number of joint solutions. One solution can

be picked from this set based on multiple criteria.

1.9. Decision Making

Noteworthy is that the fault-tolerant architecture, as defined by

Sreevijayan and Tesar [1993], relies on redundancy (alternate physical pathways)

at all levels. However, if a robot structure is designed with redundancies, it is

important that all the DOF of the manipulator be utilized during normal operation.

This is necessary to achieve better dexterity, support obstacle avoidance, and to

avoid mathematical singularities. Utilization of all the degrees of a redundant

manipulator involves solving a system with infinite solutions. This is where

decision making becomes important [Sreevijayan and Tesar, 1993]. The decision

making process in the control of redundant manipulators involves using a set of

performance criteria. These performance criteria can be energy minimization,

manipulator precision, load carrying capacity, speed of operation, or other criteria

[Hooper, 1994]. Based on a given set of performance criteria, decisions are made

as to how to achieve the desired performance. For example, for a kinematically

redundant arm, criteria-based inverse kinematics may involve computing a

solution that minimizes joint velocities. Similarly, other criteria can be



13

formulated based on geometry, inertia, energy, compliance, and dexterity

measures.

Twenty-nine different performance criteria were identified in one Master’s

thesis alone [VanDoren, 1992]. Also, Cleary and Tesar [1990] have proposed a

set of criteria that are based on the physical parameters of the robot and are

independent of the task. This allows for continuous operation without

reconfiguration if there is a task change. In addition, the work by Hooper [1994]

led to the formulation of a generalized criteria-based inverse solution for

redundant arms. Hooper’s scheme uses the direct-search technique, combined

with a set of constraints (specified by the criteria), to compute the best kinematic

configuration for performing constrained end-effector motion [Hooper, 1994].

However, the presence of multiple criteria, combined with sensory input from

various sources, poses a major problem of criteria fusion. Criteria fusion is

currently an active interest of the Robotics Research Group.

Besides criteria-based decision making, there are other issues that have to

be addressed for fault-tolerant operation of a robot arm. These are failure

detection, diagnosis and estimation, failure recovery and reconfiguration, and

failure treatment. These are necessary and required for fault-tolerant operation. It

should be noted that under normal operation of a redundant arm, the non-

determinancies are resolved based on meaningful decision making criteria. Under

failure conditions, the same redundancies are used to counteract the effects of the

failure. For a smooth transition from normal operation to operation in the

presence of a fault, it is important that the fault-detection and the associated

recovery satisfy real-time constraints [Sreevijayan and Tesar, 1993].



14

1.10. Overview

The previous sections outlined the characteristics of advanced robotic

systems and discussed some of the issues involved in robotic software systems.

The goal of this research is to develop a software architecture that best fulfills the

requirements of an advanced robotic system. Additionally, this architecture

should provide for software reuse, standardized interfaces and allow for rapid-

prototyping. Another goal of this research is to extend the direct-search technique

of generalized kinematics as proposed by Hooper [1994]. This extended

technique should be computationally efficient, general, reconfigurable, andsupport level III fault-tolerance. Based on this summary, the following

paragraphs outline the contents of this dissertation.

Chapter Two is a critical literature review. The literature review describes

robotic software systems, software design techniques, state of computer

technology, and generalized inverse kinematics. Considering this literature

review, a set of requirements for a software architecture for advanced robots is

derived. Also, an analysis of Hooper’s [1994] work in particular, and inverse

kinematics in general, provides the motivation for further developing Hooper’s

[1994] direct-search technique.

Chapter Three begins by discussing the generalized inverse problem and

then details Hooper’s direct-search technique of inverse kinematics. Based on

this discussion, the strengths and weaknesses of this technique are discussed.

This chapter then details the algorithm for using a combination of the direct-

search technique and a computationally efficient generalized inverse kinematics

scheme. This formulation is called the hybrid formulation. By using a hybrid

formulation, the advantages of the direct-search technique and computationally

efficient generalized scheme can be combined to achieve a practical



15

implementation. Further, this chapter explains the incorporation of multiple

performance criteria into the hybrid scheme. In addition, a preliminary technique

for criteria fusion is also discussed.

Chapter Four discusses the issues involved in the selection of the hardware

and software environment that was used to develop, demonstrate, and test the

software architecture in question. This involved the selection of a software design

methodology, programming language, operating system, hardware platform,

simulation environment, and robotics hardware. In addition, this chapter discuses

the managerial and organizational issues that were faced in the software

development process.

Chapter Five discusses the core of this research, which involves the design

and development of a software architecture that can best satisfy the needs of

advanced robotic systems. An in-depth analysis of the domain of advanced

robotics is presented. Considering this analysis, the domain of advanced robotics

is broken down into sub-domains. These sub-domains include mathematical

abstractions, forward kinematics, inverse kinematics, dynamics, deflection

modeling, performance criteria, and utility components. These domains are

further broken down into operational software components that have standardized

interfaces and support reuse via generality and extensibility. Details of the

analysis and design issues are provided for each component. Furthermore,

example use and the reuse potential of each operational software component is

discussed.

Chapter Six provides validation for this research. This includes

demonstrations of the software architecture. Various example programs are

shown which depict the simulation and operational characteristics of this

software. Example demonstrations for the generalized inverse and the hybrid

formulation are also shown. Additionally, example programs are given which



16

depict the extensibility and generality of the software architecture. This chapter

also discusses the experiments conducted with this software architecture. These

experiments were conducted to analyze the benefits of this software architecture

over existing implementations. The criteria used to make this analysis and the

results are discussed here.

Chapter Seven concludes this dissertation and discusses areas for future

work. This chapter discusses the lessons learnt and explains and draws

conclusions from the experimental activity that was performed as a part of this

research. The various issues faced during the analysis and design of the software

architecture are discussed. Additionally, issues relating to implementation,

integration, system control, and manufacturing cells are discussed. Also, other

areas in intelligent machine software that can benefit from a software architecture

are discussed.



17

Chapter Two

2. Literature Review

2.1. Introduction

Robots are advanced machines that incorporate technology from all

engineering disciplines. This includes mechanical hardware, computer hardware,

and computer software. It is the goal of the Robotics Research Group at the

University of Texas at Austin to design the next generation robot [Tesar, 1989]: a

robot that is based on the concepts of modularity, reconfigurability, fault-tolerance, and enhanced flexibility and performance. For this to be possible, it is

imperative to use the very best in mechanical and computer technology.

The Robotics Research Group is actively pursuing the development of

intelligent machine component technology in all three engineering disciplines

(mechanical hardware, computer hardware, and software). These components

comprise a complete set of modules that would allow building of complete

systems. For this kind of component technology to be successful, a computer

aided design (CAD) system is needed that would allow the selection of the

optimal modules. Work done in this area has led to the development of a CAD

selection process for the mechanical modules (MCAD) [Bunker, 1996], and a



18

similar CAD procedure for the electrical hardware components (CCAD)

[Ambrose, 1992]. MCAD is responsible for determining the optimum

configuration of the manipulator based on specifications and the available

mechanical modules [Bunker, 1996]. CCAD creates the optimal controller based

on available components [Ambrose, 1992]. The third sub-system of this CAD

tool is SCAD. SCAD stands for software CAD and is the tool that can optimally

select software modules for the task at hand. However, before SCAD can be

fully developed, an architecture for the software components needs to be

developed. The exact requirements of these components, their functionality,

and their interface needs to be defined. The requirements generation and

development of this software architecture is the prime goal of this research.

The software modules developed as a part of this research will span the full

spectrum of operational requirements for advanced robotics, including criteria-

based decision making, generalized inverse kinematics, dynamics, deflection

modeling, etc. These modules will be standardized to fit within a complete

architecture for the advanced robot software system and will be packaged in the

SCAD environment for interactive prioritization, selection, and integration into

the full operating system. The requirement that these modules be efficient,

portable, reliable, maintainable, and operate in real-time, is essential to the

effectiveness of the SCAD process.

Once MCAD, CCAD, and SCAD are fully developed, the next step is the

development of a system that ties all these three sub-systems together and

provides an interface to the user. This requirement has led to the preliminary

development of an Interactive Synthesis Tool for Advanced Robotics (I-STAR)

that deals with the CAD selection process. The I-STAR design environment

allows the user to interactively design a modular robotic manipulator from an

optimum population of hardware and software modules that can best meet the



19

task requirements specified by the user [Hicks, 1995]. From the informal task-

related requirements phase (also under development), the I-STAR system will

generate a complete design of the manipulator with regard to its mechanical and

control hardware in addition to generating the required operational software.

Such a system is essential for reconfiguration. Thus, the ultimate goal of the I-

STAR environment is to solve this deficiency and provide a framework by which

the manipulator system may be assembled from a unique set of mechanical,

controller, and software modules efficiently by an engineer with a B.Sc.

education. This environment should not only provide enormous gains in terms of

cost reduction, reliability and maintainability, but also in terms of a reduced threat

of obsolescence and a more rapid changeover in the component technologies. The

I-STAR environment is illustrated in Figure 2.1.

MCAD(Mechanical) SCAD(Software) CCAD(Controller)

Expert

Database

Design Validation

Simulator

System

Design

Task Specification

Advisor

Process, Task,

or Operation

Figure 2.1: The I-STAR Environment for System Design.



20

This chapter gives background information for all the above mentioned

component technologies (mechanical hardware, computer hardware, and

software) as they impact the software requirements of advanced robotics. The

current state of robotics research and industrial robots is also discussed. Further,

this chapter gives detailed information about software technology involved in

robotic systems. After this a detailed literature review of robotic software systems

is given. Analyzing the strengths and weaknesses of past and current research in

robotic software systems provides the motivation for this work. Additionally, the

current and forecasted state of computer technology is discussed.

The next part of this chapter provides a literature review of inverse

kinematics. Hooper’s [1994] work provides a basis for this literature review.

After this, the inverse kinematics scheme developed by Hooper is analyzed. This

analysis provides the motivation for further work in the area of performance-

based generalized inverse kinematics. The following sections provide a

discussion of various component technologies for robots and their impact on the

software requirements.

2.2. Mechanical Hardware

The mechanical hardware is a key part of the robotic system. This

includes the hardware for the actuators and the links. The actuator hardware

further includes sensors, brakes, clutches, motors, and gear-train. The links

provide a frame for connecting the actuators that make up the robot. There are

certain characteristics that are desired from the mechanical hardware of advanced

robots. These are modularity and reconfigurability, redundancy and fault-

tolerance, precision, and maintainability. The following sections discuss these

characteristics and the impact they have on the software requirements.



21

2.2.1. Modularity and Reconfigurability

Robots in the past have exhibited a monolithic mechanical design [Tesar,1989]. In this design, the actuators are not generally located at the robot joint.

Thus, in such a design, the actuator and the joint are connected through linkages

and universal joints. The key advantage of this design is that the total movable

mass of the robot is reduced. This is done by placing the actuators in the base of

the robot. This allows for cheaper, smaller, and less powerful actuators to be

used. The disadvantages of such a design are:

• There is no one-to-one relationship between the actuators and the robot joints.

This leads to a complex coupling between actuators and joints.

• The use of linkages and transmissions adds compliance to the system. This

design philosophy goes against the basic precept of ‘keeping the mass closer

to the input and the compliance away from the input’ [Tesar and Matthew,

1976].

• The biggest disadvantage of a monolithic design is that it is non-modular. In

this case, none of the advantages associated with modularity are present.

Figure 2.2 shows a standard industrial robot which is based on a

monolithic mechanical design.



22

Actuators for the Wrist

Actuator for the Elbow

Transmission

Shafts add

Compliance

Figure 2.2: A Six DOF Monolithic Robot.

Current trends in robotics research are to design modular robots which are

based on advanced actuator technology [Butler and Tesar, 1989]. Actuators being

developed in the research community now incorporate the motor, sensors, gear-

train, power electronics, servo-controller, and software in one self contained unit.

Such actuators can be placed directly at the robot joint. Using these actuators, a

modular robot can easily be configured as a set of actuators and links connecting

these actuators. Robots which incorporate modularity offer the advantages of

reconfigurability, extensibility, standardization, simplified mechanical

architecture, and enhanced stiffness [Butler and Tesar, 1989]. Figure 2.3 depicts asix DOF modular robot.



23

Base Actuator

Wrist Actuator

Large Actuator

Small Actuator

Elbow Actuator

Figure 2.3: A Six DOF Modular Robot.

The robot shown in Figure 2.3 is currently (July, 1996) being prototyped atthe Robotics Research Group at the University of Texas at Austin. The key

components being developed are a set of two actuator modules. The first three

joints of this robot use the larger actuator module and the last three use the

smaller actuator [Grupinski, 1996]. Figure 2.4 shows the same robot in an

exploded view where each module is shown separated from the others.



24

Base

Actuator 1

Actuator 2Link

Actuator 3

Actuator 4

Link

Actuator 5

Actuator 6

Yoke

End-Effector

Connector

Figure 2.4: Exploded View of the Modular Robot.

As mentioned earlier, the robot shown in Figures 2.3 and 2.4 exhibits

modularity and thus is reconfigurable. This means that the actuators and links of

these robots may be rearranged, or different geometry links may be used to realize

a robot more suitable to the task at hand. This characteristic of the modular

architecture adds additional complexity to the operational software, with

reconfigurability of the operational software now becoming essential for

success of this technology. Also, as the proposed mechanical architecture

realizes its benefits from the use of modular components with standardized

interfaces, it is logical to extend the application of these concepts to the robotic

software.



25

2.2.2. Redundancy and Fault-Tolerance

Once a modular and reconfigurable mechanical architecture is in place, thenext step is to develop advanced robotic devices that exhibit redundancy and

fault-tolerance. Redundancy entails the use of more DOF than the bare minimum

required for the task. Redundancy has the advantages of flexibility, increased

performance, and fault-tolerance. An example of a redundant robot arm is shown

in Figure 2.5. This robot has ten DOF and has a fault-tolerant mechanical

architecture.

Figure 2.5: A Ten DOF Fault-Tolerant Manipulator.

The presence of redundancy and fault-tolerance adds a great deal of

complexity to the robotic software. The biggest reason for this complexity is the



26

complete change of the domain the software is dealing with. This is because most

of the algorithms and control schemes that apply to non-redundant robot arms are

no longer valid for redundant arms. Also, greater performance is desired from a

redundant mechanical structure. It is the software that has to extract this

performance. The software now has to support generalized kinematics, dynamics,

performance criteria, decision making, and criteria fusion (see Chapter One for a

description of these constructs).

A four-level fault-tolerant mechanical architecture has been defined by

Sreevijayan and Tesar [1993]. This architecture is subsumptive in a sense that the

effects of a fault are not transferred to other layers. The support for fault-

tolerance in the mechanical architecture adds stringent real-time constraints to the

software. Software sub-systems now have to be developed for fault-detection and

identification, fault-tree analysis, and real-time resource allocation [Sreevijayan

and Tesar, 1993]. Additionally, the software itself has to support fault-tolerance.

This is necessary because a fault-tolerant system is only possible if all its sub-

systems exhibit fault-tolerance. As a part of the fault detection and identification

sub-system, software has to be developed for accurate modeling of the robot being

controlled. By comparing the results of the robot modeling software with input

sensor data, aberrations in the robot behavior can be detected. This assists in fault

detection and isolation.

2.2.3. Precision

A majority of current industrial robots are used for simple tasks (pick and

place) that involve little precision work [Tesar, 1989]. As mentioned earlier,advanced robots are being developed that are based on modularity, performance

and fault-tolerance. The full potential of these robots can only be realized if they

are used for “real” manufacturing applications, that is, high-speed and precision



27

applications that are currently being handled by fixed-automation machines.

Currently the Robotics Research Group is developing a prototype high precision

seven DOF manipulator [Marrs, 1996]. This robot is characterized by a

mechanical structure with minimal compliance and backlash (average deflection

of 0.01 inches and one arc-second of lost-motion) [Marrs, 1996]. Again, the

software will be key to exploiting the functionality of this robot. Under operation,

there will be force-related disturbances created due to the manufacturing process.

Also, the robot end-effector will not be able to maintain desired absolute location

due to compliance in its links and joints under loads. To counteract these

problems it is necessary that the control software compensate for mechanical

deflection and reject disturbance effects.

2.2.4. Maintainability

The development of an advanced mechanical architecture, as the one

proposed in the previous sections, is a costly endeavor. The reliability of these

systems will have to be guaranteed for their effective utilization. Additionally,

down-time, if any, should be minimum for these machines. For this to be

possible, the failures of these machines should be predictable. To achieve this

level of maintainability, unprecedented demands will be placed on the software of

these machines. These machines will be data-base driven. Under operation, the

performance of these machines will be continuously monitored and the empirical

data collected and archived in real-time. This data will then be used for

condition-based maintenance. Continuous comparison of a parameteric model of

the machine to the actual machine condition derived from on-board sensors willalso provide a time-sheet for maintenance. Similar technology is already being

made available in today’s automobiles. Electronics, software, and transducers are

effectively being used in today’s cars to detect and inform the user of the



28

impending maintenance. It is desired that a similar infusion of technology take

place in the intelligent machines arena.

The previous paragraphs discussed the advanced mechanical architecture

of intelligent machines. This architecture is based on modularity,

reconfigurability, fault-tolerance, precision, and maintainability. The

requirements placed on the software due to these characteristics was also

discussed. Table 2.1 summarizes the attributes of a mechanically advanced robot

and shows their impact on the requirements of the software for these robots.



29

2.3. Computer Hardware

Once a modular, reconfigurable, and fault-tolerant mechanical architecture

is in place, the next step is the development of the control and operational

software for the robot. The computer hardware and electronics provide the

Mechanical Characteristic Software Requirements Modularity − Modularity

− Standardized Interfaces

Reconfigurability − Reconfigurability

− Generality

− Software CAD System

Redundancy − Obstacle Avoidance

− Decision Making

− Performance Criteria

− Criteria Normalization

− Criteria Fusion

− Performance-based Kinematics

− Sequential Filters

Fault-Tolerance − Real-Time Reconfigurability

− Real-Time Error Handling

− Safe Termination

− Resource Allocation

− Fault Tree analysis

− Failure Detection and Identification

− System Modeling for Referencing

− Software Fault-Tolerance

Precision − Deflection Modeling

− Dynamics

− Disturbance Rejection

− Strict Real-Time Constraints

− Sensor Fusion Maintainability − Real-time Data-base Driven

Machines

− Model Referencing

− Sensor Referencing

− Condition-based Maintenance

Table 2.1: Impact of Mechanical Hardware on Software Requirements.



30

software execution, control and interfacing environment. Section 1.4 had outlined

two major layers of robot control. These were the servo level and system level

control. Both these layers have different software requirements and real-time

constraints. The servo level layer is responsible for the real-time control of the

actuators and has stringent temporal constraints. The system controller is

responsible for operational software and robot programming. The two hardware

layers and their impact on the software requirements is discussed in the following

sections.

2.3.1. Servo-Level Hardware

As stated earlier, the two major software sub-systems have different

software requirements. This difference is also reflected in the computer hardware

and electronics used for the two layers of robot control. At the servo level, power

amplifiers are used to supply current to the actuators. The current is regulated

based on the desired torque output of the actuator. A PID (proportional, integral

and derivative) control loop is generally used to control the position, velocity, and

acceleration of the actuator.

This research is focusing on developing a reusable operational software

architecture. A similar effort is needed in the area of actuator control software.

This software will execute on the servo-level hardware and will have stringent

real-time constraints. Section 7.4.3.1 discusses the issues involved in actuator

control and suggests a preliminary software architecture.

Two approaches are possible for servo-level hardware design. These are

based on centralized control and distributed control. These are discussed in thefollowing sections.



31

2.3.1.1. Centralized Control

Most industrial robots use analog servo-controllers. These controllers arehardware intensive and are normally placed external to the actuator [Puls, 1994].

Bulky current and sensor cables are used to connect the actuators to the servo

controllers. This type of control setup is also known as centralized control

because all actuator control is done outside of the robot in one large control unit.

An example of such a system is the Cincinnati Milacron Inc. T3-776 industrial

robot. This robot requires 24 wires for the tachometers, 54 wires for the

resolvers, 18 wires for the brakes, 40 wires for powering the motors and cooling

system, and 15 spare wires (a total of 150 wires) [Puls, 1994]. These cables have

to be routed back to the servo-controllers (placed externally) through the

mechanical structure of the robot. Such a system that uses centralized control is

illustrated in Figure 2.6.

System

Controller1 32 4

Actuators

Figure 2.6: Centralized Control Structure [Puls, 1994].



32

2.3.1.2. Distributed Control

The current trend in robotics research is to develop digital servocontrollers that can be placed inside the actuators. This entails the use of digital

power electronics and an embedded computer which is used to execute the servo-

loop to control the output of the actuator. This technology greatly reduces the

cabling involved in a robotic system and makes the actuator a completely self-

contained unit. Quoting Puls [1994], “depending on the types of power and

communication buses this total number of wires could be less than ten.” This is a

fifteen times reduction over the number of cables used in the T3-776 robot. An

example of the distributed control technology is the Digital Intelligent Servo

Controller (DISC) [Aalund et al., 1993] which accepts position, velocity, or

torque set-points from the system controller. A total of eleven wires is used to

connect a DISC to the system controller and the power supply [Puls, 1994]. A

distributed control structure is illustrated in Figure 2.7.

The previous paragraphs discussed the transition of servo-control

technology from centralized control to distributed control. As a part of this

System

Controller 1 32 4

Actuators

Communicationand Power Bus Local Controllers

Figure 2.7: Distributed Control Structure [Puls, 1994].



33

research it was necessary to gauge the impact of this transition on the software for

robotic systems. Unlike the impact of advancements in mechanical technology on

software (where the complexity of the software increased), advancement in servo-

control technology simplifies the software requirements. Under distributed

control, a clear boundary is placed between the system controller software (part of

this research) and the servo-control software. The system controller under

distributed control now treats the servos as slave black-boxes that just follow

orders. Under centralized control, the system controller had to often support

software for servo-control [Aalund, 1991]. This complicated the software, broke

down its modularity, and imposed stringent real-time constraints.

2.3.2. System Controller Hardware

As mentioned earlier, the other sub-system in robot control is the system

controller. The purpose of the system controller is to execute the operational

software, provide the robot programming environment, interface to peripheral

equipment, and send position, velocity, or torque set-points to the servos. The

hardware for such a system uses computers that have extensive interfacing

capabilities (serial ports, Ethernet, etc.), and have additional slots which can be

used to plug in new hardware (digital IO cards, etc.). Additionally, system

controllers require a CPU that has a greater than 1 MFLOP floating point

capability [Ambrose, 1992]. This is because the robot kinematics has to be

computed on the system controller in real-time. However, as mentioned in the

first chapter, kinematics by itself is not sufficient for robot control. Additionally,

the kinematics of redundant robots involves numerical algorithms and requiresgreater computational power. Ambrose [1992] specified the need for 115

MFLOPS to control a redundant dual-arm manipulator with 10 performance

criteria and an update rate of 100 Hz.



34

Robotics research in the development of system controllers has taken four

different approaches to tackling the hardware requirements. The first approach is

to use rack mounted computers which have many available slots (around ten,

Aalund [1991]) that can be used to connect peripheral equipment. This approach

relies on off-the-shelf hardware. An example of this approach is the multi-

channel robotic controller developed by Aalund [1991].

The second approach to system controller development involves the use of

specialized hardware for compute intensive tasks. This becomes necessary when

the standard computer hardware cannot satisfy the computational needs of the

robot being controlled. An example of this approach is the use of a pipelined

array processor to compute the dynamic model of a robot arm [Wander, 1987].

Using this system Wander was able to compute the complete dynamic model of a

six DOF industrial robot in less than 5 milliseconds.

The third approach to system controller development involves developing

specific computer architectures and hardware for robotics [Ambrose, 1992]. This

was necessary as generic computer hardware was only able (because of its speed

limitations) to compute closed-form inverse kinematics. For example, an Intel

80386-based personal computer (a two MFLOP processor) took more than 100

milliseconds to compute the complete dynamic model of a six DOF robot

[Ambrose, 1992]. Also, various computationally complex mathematical

formulations (dynamics, generalized inverse) required greater than 10 MFLOPS

each and were thus not possible on general purpose hardware.

The fourth approach, which is rapidly gaining popularity, relies on using

standard commercial computer hardware (for example a personal computer) as the

system controller. This has been possible due the increasing computational power

and decreasing cost of commercial computers. Currently (May, 1996), desk-side

uniprocessor computers offer 400 MFLOP performance (R10000 RISC



35

Microprocessor from MIPS) (refer to Section 2.7 for details on past and current

computer technology). Another advantage of this approach, besides cost and

user-preference, is the availability of software development tools that allow for

easier and state-of-the-art program development (see Chapter Four for details on

software development tools and their selection process). Examples of commercial

system controllers that use personal computers are the system controller from

Cimetrix Incorporated [1996]. This controller uses a Intel Pentium 90 MHz.

CPU as the processor and Windows NT as the operating system and has a total of

thirteen bus slots (ten ISA bus, two PCI bus, and one ISA/PCI).

2.3.3. Computer Bus

Another crucial factor in the development of robotic computer hardware is

the selection of the computer bus, which provides the high-speed communication

link between the system controller and the servo-level control making digital

control possible throughout the system. Potter [1992] details different bus types

and the factors to consider when selecting a bus. Section 4.3.2.2 details some of

the commercially available computer buses and outlines a selection process for

these buses. In brief, it is seen that the bandwidth of computer buses has steadily

increased. For example, the XT bus (used in personal computers in the early

1980’s) has a bandwidth of 800 Kbytes/sec. Currently, the Turbo Channel bus

used in Digital workstations has a bandwidth of 98,000 Kbytes/sec (an

improvement of approximately ten-times each year). The next paragraph

discusses the impact on the software requirements due to advancement in servo-

level control and system controller technology.Section 2.3 discussed the computer hardware technology involved in robot

control. It was mentioned that a distributed control scheme simplifies the

software development process. This is because it leads to a “separation of



36

concerns” approach. The system level software no longer has to worry about

satisfying the servo-level real-time constraints and event handling. The next thing

discussed in this section was that system controllers have steadily gained in their

price/performance ratio (an increase by a factor of 20 between 1989 and 1992,

Ambrose [1992]), with a trend towards general purpose hardware. This

development again has a positive impact on the software requirements. Programs

that were written ten years ago in low-level assembly language can now be written

in high-level object-oriented languages. Additionally, the availability of higher

computing power (greater than 100 MFLOPS) allows the development and use of

generalized algorithms that are compute intensive but serve a larger variety of

machines. Additionally, the increase in bus bandwidth allows for faster

communications between processors in a multi-processor system, thus making the

required software protocol more efficient. Also, the real-time constraints of the

software are less stringent for higher bandwidth systems because less time is now

spent communicating. This impact of the advancement in robot control hardware

on robotic software is summarized in Table 2.2.



37

2.4. Software

A scaleable, distributed, and computationally efficient control hardware

architecture combined with an operating system results in an execution

Controller Characteristic Software Impact and RequirementsServo Level

Distributed Control Vs.

Centralized Control − Cleaner well defined software architecture

− Real-time constraints not as stringent

− Distributed approach to software structure

− Need for a software architecture for actuatorcontrol (see Section 7.4.3.1)

System Level

Scaleable Multi-processor

Architecture− Develop multi-processing software

− Need for advanced software development tools(see Chapter Four for details)

− Software has to encapsulate the scaleability of the hardware

− Greater reliance on operating system software

Increase in Processor Speeds − Use of generalized algorithms

− Higher level programming languages

− Balance shifts from efficient coding to reusabledesign

Move Towards General

Purpose Commercial

Hardware

− Availability of a large array of softwaredevelopment tools

− Leverage off advancement in commercialsoftware

− Availability of a variety of operating systems

− Large base of skilled software developers

− Higher expectations from robotic software

Computer Bus Advancement in Bus

Technology− Multi-processor software development is

feasible due to higher bandwidth

− Bus technology now allows for tight couplingof a large number of distributed devices. Thiscalls for a distributed software architecture

− Real-time constraints relaxed due to higherbandwidth

Table 2.2: Impact of Control Hardware on Software Requirements.



38

environment for robot software. Software is a key component of a robotic control

system and can be thought of as the “brains” of the system. It is the software that

extracts the functionality of the robot, makes it easier to use, and minimizes the

integration cost. According to Smith [1992], a robot may cost roughly $20,000 to

$100,000. However, as most applications require custom setup, the cost of

software and engineering can raise the total cost to greater than $200,000.

Another insight into robotic systems was gained while talking to automation

engineers from Ford Motor Company. The engineers were asked about what they

wanted most from their robotic system. The options given to them were,

modularity, reliability, and ease of integration. Surprisingly, the engineers said

that they would like to see software that supports rapid-prototyping and allows for

easy integration. Reliability was also an issue, but according to the engineers,

they had not had a robot breakdown in three years. Mechanical modularity,

though desired was not a top priority amongst the Ford engineers. This was

because the cost of the mechanical robot arm was 20% of the total robot setup

cost. Also, Ford counteracted the threat of robot functionality not meeting the

application requirements by purchasing arms that had more functionality than

needed. However, this should not be taken as an argument against modularity.

This is because Ford is one of the largest buyers of robot arms. Smaller

manufacturing units may not find it feasible to stock spare robots or to buy robots

with extra functionality to just counteract the threat of obsolescence. The solution

to these problems is a modular reconfigurable arm that adapts to meet the needs of

the application coupled with a software environment that supports rapid-

prototyping and efficient integration. Tesar [1996] discusses details of the issues

that have to be addressed for automation of automotive plants.

On the mechanical side, a modular architecture already helps in rapid-

prototyping and reconfiguration. On the control hardware side, a distributed



39

control approach combined with a scaleable architecture and standard

communication bus types helps in rapid-prototyping. The remaining technology

that needs enhancements to support rapid-prototyping is software. Software now

needs to be addressed as a commodity that can be bought off-the-shelf,

assembled, modified, and reused. The examples given in the previous paragraph

assert this need. The need for standardized reusable software components is even

greater for advanced robotics because there software is going to be larger and

more complex. The examples (Ford Motor Company and Smith) given in the

previous paragraphs were based on standard industrial robots, that is, monolithic

mechanical arms with six DOF. Software cost is going to be even higher for

advanced robots. Thus, what is needed is a development effort into the design

and testing of operational software modules for advanced robotics. A preliminary

listing of some of the required software modules for advanced robot control is

given in Table 2.3 [Tesar, 1993]. The modules are broken down into components

for actuator level control and for system level control.



40

The previous sections discussed the need for research into robotic software

and also outlined specific areas in which development should take place. What

needs to be assessed is how robotic software can leverage off the advancement in

software technology. First the past and current state of software technology is

discussed.

2.5. Software Technology

Some areas of software technology were assessed for this research. The

most important of these was the software design methodology. This is because it

was desired to use a software design methodology that supported modularity and

reusability. The other areas of software technology that were analyzed were real-

time software, operating systems, and programming languages. Under software

design methodologies, structured design and object-oriented design were

Module Function Number of Distinct Modules Required

Actuator Level

Sensor data reduction 20

Brakes, clutches, prime movers 10

Control algorithms 15

Fault detection and identification 20

System Level

Graphical user interface 10

Geometric properties of manipulator 5

Compliance properties of manipulator 5

Dynamic properties of manipulators 5

Generalized inverse of manipulators 10

Obstacle avoidance procedures 5Performance criteria for manipulators 50

Resource allocation and scheduling 15

Electronic device drivers 10

Communications and multiplexing 10

Table 2.3: Listing of Required Software Modules.



41

explored. Under operating systems, standard operating systems like UNIX and

Windows NT were explored. Realizing the limitations of these operating

systems, real-time operating systems were analyzed. Programming languages

were analyzed keeping in mind their support for modular design (see Section

4.2.2).

2.5.1. Software Design

Mature industries like manufacturing are characterized by the presence of

component industries. For example, an automobile is made up of various sub-

systems, where each sub-system could possibly be supplied by a different vendor.

This is also the case for computer hardware. The software industry, which has

become a significant wealth generator, has a minimal component industry. This is

essentially due to the inherent complexity of software, lack of standardization, and

lack of a unifying software design paradigm.

The following paragraphs discuss the two predominant software design

techniques (structured and object-oriented). Of these, object-oriented design may

very well provide a solution to some of the problems faced by those developing

software for intelligent machines.

2.5.1.1. Structured Design

Since the advent of computer technology, there has been a shift from

programming-in-the-small to programming-in-the-large. The software industry

has also seen the evolution of high order programming languages. Various

software design methodologies have also evolved in the past. Of these, the most

popular is structured design. This design paradigm is also known as functional

design and procedural design. The structured design paradigm uses algorithmic

decomposition to specify tasks to be completed in order to solve a problem. This



42

design methodology is typically characterized by procedural languages like C and

Pascal. Structured design relies heavily on data flow, where data flows from one

procedure (sub-routine) to another, thereby undergoing transformations. Thus, a

task is divided into procedures, and each procedure is further sub-divided. This is

also known as top-down structured design [Yourdon, 1979].

In structured design, data and instructions are kept separate. Data flows

from one sub-routine (set of instructions) to another and undergoes

transformation. For example, in robot path planning, the data corresponding to

end-effector position can be changed to joint position data by applying the inverse

kinematics sub-routine to it. This style of programming is illustrated in Figure 2.8

[Booch, 1994].

2.5.1.2. Object-Oriented Design

The other key software design methodology that is rapidly gaining

popularity is the object-oriented design. This design methodology professes that

software systems should be modeled as a collection of cooperating objects,

treating individual objects as instances of a class within a hierarchy of classes.

Input Data Output Data

Interface

Procedure

Interface

Procedure

Interface

Procedure

Figure 2.8: Structured Program Design.



43

Thus, the first step in the analysis of the problem domain using object-oriented

techniques involves identifying the key objects that make up the system. Objects

with similar characteristics are part of an inheritance structure that is used to

extract the benefits of commonality. Each object has a standard interface through

which it communicates with other objects. Additionally, each object contains its

own functionality. This is similar to the way physical systems and entities exist.

As a result of this similarity, the structure of an object-oriented software ends up

resembling that of the physical problem domain [Booch, 1994]1. Five General

concepts of object-oriented design are discussed in the following section. These

are, classes, data abstraction, inheritance, polymorphism, and dynamic binding.

The first three appear in high level design and analysis. The last two are added

during low-level design and implementation [Korson and McGregor, 1990].

2.5.1.2.1. Classes

Classes in object-oriented design are used to define a group of objects with

similar characteristics. This can be explained best by a real world example. A

can (food packaging) class can be defined that would include all sorts of cans

ranging from soda cans to paint cans. When the can class is defined, the designer

has to define the interface to this class. This means deciding what is visible to the

user. For example, for the can class, the interface could consist of a function

which returns the capacity of the can (get_capacity) and another function which

returns the contents of the can (get_contents). These functions (called methods in

object-oriented design) would be implemented as an integral part of the can class

and will be visible from outside the class. These visible methods are known aspublic methods. Other methods are also defined by the designer which are used to

1 In the past procedural design and software parallelism was used to structure software. Object-



44

calculate data which is needed by the public methods. For example, a method can

be implemented which calculates the volume (calculate_volume) of the can. The

output of the calculate_volume method will be used by the get_capacity method.

Thus, there would be no real need for exposing the calculate_volume method to

the user. In other words, calculate_volume can be made a private method of the

can class. Thus, by implementing a method as a private member, the software

designer makes sure that it is not visible to the world outside the class. This

technique of hiding data is called encapsulation and is used for data abstraction.

Data abstraction will be discussed in more detail in the next section.

Besides having public and private methods there are two other constructs

which are a part of the class and are used in object-oriented design. In C++ these

are called the constructor and destructor . A constructor is used to create an

instance of a class. This instance is also known as an object. The can analogy is

referred to again to explain instantiation. In the real world, when a can is

designed on paper, the designer lays out the characteristics of the can. These

characteristics would be general purpose rules which would define the behavior of

a can. When a can gets manufactured and gets a distinct identity (example, a

Coke can) it is called an object. Thus, from the can class defined above, different

objects of the type can, can be instantiated. These objects can have different

capacities and contents. An implementation of the can class in pseudo code is

shown below:

Class can{

public methods:

constructor(...........);

destructor(..............);get_capacity(.........);

get_type_of_contents(.........);

oriented design now offers another means of defining software structure.



45

private methods:

calculate_volume(....);evaluate_content_type(.......);

}

In object-oriented design when an entity of a particular class type is

created, it is called an object. For example, from the can class if a can with a

volume 20cc and contents soda is created, it will be called an object. These

objects form the basic run-time entities in an object-oriented system. Objects take

up space in memory and have an associated address like a data type in FORTRAN

and C. Associated with every object is a set of methods that define the

meaningful operations on that object. In traditional procedural programming a

new data type can be defined but the methods which act on this data type are

separate and are in the form of sub-routines.

The destructor used in C++ is used to deallocate the memory allocated to

an object and thus stop its existence.

A more related example of a class would be a matrix class. The matrix

class in all probability will have public methods for multiplication, inversion, and

transposing. There can be some private methods for doing memory management

and other methods implementing different matrix inversion techniques. The

implementation of the matrix class would look somewhat as shown:

Class matrix{

public methods:

constructor(row, column);

destructor(..............);

invert(.........);multiply(.........);

add(..........);

transpose(.........);

private methods:



46

adjoint(.......);

set_up_sparse_matrix(........);

private data:real A[i][j];

}

Instantiation of an object of type matrix would be similar to instantiating a

simple integer. For example, the statement “matrix B;” would create an object

‘B’ of type matrix. All the methods shown in the matrix class above would be a

part of the object ‘B.’

2.5.1.2.2. Data Abstraction

Various abstraction mechanisms are available in programming languages.

Procedural abstraction, for example, is based on parameterizing a programming

unit (sub-routine), that is, allowing the same processing steps to be applied to

different data. Data abstraction, on the other hand, separates the behavior of a

data type from its implementation. Users of the data type see only its external

view (that is the set of operators), allowing its implementation to be modified

without adverse effects. This data hiding is known as encapsulation. To fully

encapsulate a data type, operators on it must be adequate, that is, they must be

fully capable of constructing, observing, and (possibly) modifying instances of a

data type [Korson and McGregor, 1990]. An example of an Abstract Data Type

(ADT) is the matrix class. To the user what is visible is the interface to the

methods (multiplication, inversion, transposing) embedded in the class (see

Figure 2.9).



47

Inversion

Multiplication

Transposing User

Implementation(invisible)

Figure 2.9: Abstract Data Type Matrix.

The implementation of the methods in an ADT is not the user’s concern

and these procedures can be changed any time without affecting the rest of the

program. Abstract data types are used to break down the design and

implementation of an engineering analysis program into separate levels of

concern. Programs designed in this manner display a number of levels of detail,

allowing developers to reason about program fragments in terms of abstract

behavior instead of implementation. The benefits of data abstraction include a

reduction in the amount of detail needed to understand program behavior, an

improvement in program structure and modularity, and an ability to easily change

implementation details.

2.5.1.2.3. Inheritance

Inheritance is a relation between classes that allows for the definition andimplementation of one class to be based on that of other existing classes.

Inheritance is the most promising concept which helps in realizing the goal of

constructing software systems from reusable parts, rather than hand coding every



48

system from scratch. Inheritance not only supports reuse across systems, but it

directly facilitates extensibility within a given system. Whenever a class Y

inherits from class X, then class Y is the derived class and class X is the base

class. The derived class Y gets all the characteristics of the base class X in

addition to all the new characteristics which can be given to it. The derived class

can also redefine some of the characteristics it inherits. An example of

inheritance as applied to the matrix class is shown in Figure 2.10. [Korson and

McGregor, 1990]

Matrix

Upper Triangular Lower Triangular Symmetry

Base Class

Derived Classes

Figure 2.10: Matrix Class Inheritance.

As shown in Figure 2.10, the derived classes upper triangular , lower triangular and symmetry are derived from the base class matrix. These derived

classes inherit all the functionality (inversion, etc.) of the class matrix. New

features can be added to these derived classes as needed. Also for the upper

triangular derived class, the multiplication feature may be redefined in a more

efficient manner. The multiplication procedure for the matrix and all its derived

classes can have the same name (in fact this is desired). Now every time the user

tries to multiply two matrices, the right multiplication procedure will be invoked

depending upon the type of the matrix. This characteristic leads us to the concept

of polymorphism.



49

2.5.1.2.4. Polymorphism

In general, polymorphism means the ability to take more than one form.In an object-oriented language, a polymorphic reference is one that can, over time,

refer to instances of more than one class. Polymorphism allows the user to have

functions with the same name. For example, if actuator joint position data is

desired from a robot controller, the applications writer has to just call the function

get_position_data. The device which is delivering the data can be a tachometer, a

resolver or a potentiometer. All these devices will probably be represented as

derived classes of a base class called position_devices.

Polymorphism allows operator overloading. Under this the operators (e.g.

+, -, *, etc.) can be redefined to act on other data types besides integers and reals.

In an application to the matrix class, the operator ‘+’ can be overloaded to act as

an operator for matrix addition.

2.5.1.2.5. Dynamic Binding

The binding referred to in this section is the binding of a procedure call to

the code to be executed in response to the call. Dynamic binding means the code

associated with a given procedure call is not known until the moment of the call at

runtime. For example, the multiplication procedure call for the class matrix is

dynamically bound to a particular multiplication procedure depending upon the

derived class of matrix which is requesting this procedure. Inheritance is

successfully used by incorporating dynamic binding. For example, consider a

software architecture for position sensors. In this architecture, there is a software

component called PositionSensor and two other components named Encoder and

Resolver that are derived from PositionSensor . All these components have

functionality for reading the position. Let this method be known as GetPosition.

When the GetPosition method is called by the user, the correct functionality for



50

accessing the position will automatically be called (or dynamically bound) based

on the type of the PositionSensor (that is, Encoder or Resolver ). The user of this

architecture has to only familiarize themselves with the interface provided by the

PositionSensor component. Future users of this architecture can add other

position sensors. The control program that was written using the PositionSensor

interface will simply incorporate the change in the position sensor with minimal

source code changes. This characteristic of object-oriented design allows

designers to develop programs at an abstract level

2.5.1.3. Object Oriented Support for Good Design

Object-oriented design inherently supports (and enforces) some of the

characteristics of a good design. These are modularity, information hiding, weak

coupling, extensibility, and integrability. These are discussed below:

Modularity: The object-oriented paradigm provides natural support for

decomposing a system into modules. In this paradigm classes are the modules.

This means that not only the design process supports modularity, but the

implementation process supports it as well through the class definition. [Korson

and McGregor, 1990]

Information Hiding: The class constructs support information hiding

through the separation of the class interface and the class implementation. The

separation allows the class interface to be mapped to several different

implementations. It also allows much maintenance activity to be hidden from

users of the class. For example, the implementation of the inversion procedure of

the matrix class can be hidden from the user. [Korson and McGregor, 1990]Weak Coupling: Classes are designed as collections of data and the set

of allowable operations on the data. Therefore, the interface operators of a class

are inward-looking in the sense that they are intended to access or modify the



51

internal data of the class. This leads to fewer connections between the classes.

[Korson and McGregor, 1990]

Extensibility: The object-oriented paradigm produces designs that are

easily extended. The inheritance mechanism supports extending designs in two

ways. First, the inheritance relation facilitates the reuse of existing definitions to

ease the development of new definitions. As the inheritance structure becomes

progressively deeper, the amount of specification and implementation inherited by

new class definition grows. This usually means that as the inheritance structure

grows, the amount of effort to develop a new class decreases. Second, the

polymorphic property of the typing system in object-oriented languages also

supports extensible designs. [Korson and McGregor, 1990]

Integrable: The object-oriented design process produces designs which

facilitate the integration of individual pieces into complete designs. The narrow,

clearly defined interface of a class supports integration with other software

components. The narrow interface corresponds naturally to the observable

behaviors of the real-world entity modeled by the class. The interfacing of two

classes then is as a model of the natural interaction of the two entities. [Korson

and McGregor, 1990]

Over structured design, object-oriented design offers the advantages of

modularity, encapsulation, standard interfaces, abstraction, reuse, extensibility,

and maintainability [Booch, 1994][Champeaux et al., 1992]. The object-oriented

programming paradigm is commonly identified by programming languages like

C++, SmallTalk, Ada, ObjectPascal, Lisp, etc. Of all these languages, C++ has

gained much popularity. This is primarily due to its design features and

compatibility with the C programming language [Jordan, 1990] (see Section 4.2.2

for details). Booch [1994] outlines some of the applications that can benefit from

object-oriented program design. Some of these are listed below. The



52

technologies that directly affect advanced robotics and could benefit from object-

oriented design are highlighted.

• Air traffic control • Animation

• Avionics • Banking and insurance software

• Business data processing • Chemical process control

• Command and control systems • Computer aided design

• Computer aided education • Petroleum engineering

• Computer integrated

manufacturing

• Software development

environments

• Expert systems • Hypermedia

• Image recognition and vision • Mathematical analysis

•

Medical electronics •

Office automation• Operating systems • Reusable software components

• Robotics • Databases

• Space station software • Spacecraft and aircraftsimulation

• Telecommunications • Telemetry systems

• User interface design • VLSI design

Various analysis and design techniques for object-oriented software

development have been proposed by researchers. Based on requirements and user

preferences, an analysis and design methodology can be chosen [Booch, 1994][Shlaer and Mellor, 1988]. However, all these design methodologies agree on a

basic three-phase life cycle for software development: 1) analysis, 2) design, and

3) implementation. The analysis phase covers the initiation of the project through

to user’s-need analysis and to a feasibility study. The design phase covers the

various concepts of the system design, broad design, logical design, detailed

design, program design, and physical design. After the completion of the design

phase the software enters the implementation phase. The whole process is

iterative, and there is communication back-and-forth between each design phase

[Henderson-Sellers and Edwards, 1990].



53

2.5.2. Real-Time Software

The implementation of robot control software is essentially a problem inthe domain of real-time computing. Fault-tolerance adds a new challenge to real-

time software as it addresses the need for deterministic software techniques for

fault detection and recovery. Real-time software is characterized by a system that

not only produces logically correct results, but also produces them in a timely and

deterministic manner. It is a common misconception that “if it is fast enough it is

real-time.” Speed of execution, though a critical requirement, is not the only

characteristic of a real-time system. A real time system should be able to respond

to external events efficiently without violating the temporal constraints associated

with such a system. The external events can be of the following types:

• multiple asynchronous external events,

• multiple cyclical external events, or

• a combination of the above [Stankovic, 1988].

Real time software can be designed in different ways with the main

purpose to respond to external events in a timely fashion. These approaches are

the ad hoc style and the multitasking approach. These approaches are discussed

in the following sections.

2.5.2.1. Ad Hoc Approach

In the ad hoc style of developing real time software, the software is

designed to function in the form of a loop. As the software goes through the loop,

it services each external event and performs calculations. This is illustrated in

Figure 2.11.



54

Joint TorqueCalculation

InverseKinematics

Sensor I/O

Servos

Torque SetPoint

Figure 2.11: Ad hoc Style of Real-Time Software Design.

In the example shown above, the software loop goes around checking the

servos for input requests, then checks sensors for I/O and then does the

kinematic/dynamic calculations. To get this working, the designer has to tune this

system by trial and error so that the torque set points are output at the rate required

by the servos. If no system change is expected, this setup would work well. But

in the case of a modular, evolutionary system there is a good chance that another

task might be added to the system. For example, if a welding sensor is added, an

additional task of reading the sensor and then taking the necessary action is added.

This has an adverse affect on the timing of the system which was earlier tuned to

output the torque set points at a particular rate. Thus, the designer has to again

fine tune the system and quite possibly rewrite the software. Worse yet, alternate,

less refined algorithms or, perhaps, more expensive hardware, might have to be

used to meet the temporal constraints.



55

2.5.2.2. Multitasking Approach

In the other approach of real time software design, the problem posedabove would be tackled by making each job a separate task, with each task

maintaining its own temporal constraints. In this methodology, the addition of a

job leads to the creation of another task which is the only task that must be tuned

by the designer. In such a system, each task functions as an independent entity

and communicates with other tasks using shared memory or other inter-task

communication techniques (see Silberschatz [1994] for details on inter-task

communications). All these tasks run simultaneously, with each task getting a

time slice of the CPU. Also, each task can be assigned a priority that defines how

often it executes or which task executes if the resources are scarce. Tasks with

higher priority get more of the CPU time compared to tasks with lower priority.

Also, the priority of each task can be changed to account for changes in the

physical system which is being controlled. For example, in the event of a fault,

the fault-handling task, which under normal operation had a low priority, must

now be run at the highest priority. This priority-based, preemptive scheduling of

tasks in real-time software is critical for the development of software for

advanced manipulator systems. The system described above is illustrated in

Figure 2.12.



56

Joint TorqueCalculation

InverseKinematics

Force/TorqueSensor Check

Real Time

Multi-Tasking Kernel

Polled Events Interrupt Events

Figure 2.12: Task-Based Real-Time Software Design.

As shown in Figure 2.12, the external world interacts with the software via

the real time multi-tasking kernel. The job of the kernel is to provide a utility to

the software developer which allows for creation and property adjustments of

tasks.

Currently, the most popular design methodology for real-time software

development is structured design. Object-oriented programming has seen lesser

popularity in this area because of its heavy reliance on dynamic memory

allocation and dynamic binding. Application of object-oriented programming to

real-time software development is a promising and active area of research [Bihari,

1992].

2.5.2.3. Real-Time Operating Systems

The first computers to be developed had no operating system software[Silberschatz, 1994]. With the advancement in computer hardware and software,

operating systems came into being. An operating system is the core of present

day computers and provides the user with an environment to manage the low level



57

details of the execution of software. Some important functions of an operating

system are process management, memory management, and file system

management. Popular examples of operating systems are UNIX, Windows NT,

OS/2, etc. However, these operating systems were developed for normal program

execution rather than real-time execution of software. Thus, there was a need for

real-time operating systems that would facilitate software development for real-

time systems.

Real-time operating systems are based on the complementary concepts of

multi-tasking and inter-task communication. The various tasks that execute on a

real-time system have priorities, and a high priority task has the authority to

preempt a low priority task in the event of resource scarcity (CPU power). UNIX,

even though a multi-tasking system, does not allow preemption of processes and

thus is unsuitable for real-time software execution. However, most commercially

available UNIX systems offer kernel extensions that support the development of

real-time software [Silberschatz, 1994]. Commercially, a large number of real-

time operating systems are available for real-time software development and

execution [Landman, 1996]. The research community has also developed real-

time operating systems for specific applications. CHIMERA is a real-time

operating system developed at Carnegie Mellon University and is characterized by

a high performance real-time kernel that supports preemptive priority-based

process scheduling [Schmitz, 1989]. RCCL was a major effort in robot control

and was based on the use of UNIX for real-time control. Hayward and Paul

developed the RCCL system by modifying the UNIX kernel for real-time software

execution. On top of this system they developed a robot control C library (RCCL)

to aid the user in developing robot programs or for testing various control

algorithms [Hayward et al., 1986]. In brief, the key factors to consider in the

selection of a real-time operating system are:



58

• Is the desired hardware platform supported?

•

What is the interrupt latency time (should be as small as possible)?• What is the context switch time (time to switch between tasks should be as

small as possible)?

• Are good software development tools available (compilers, linkers, debuggers,

performance analyzers, etc.)?

• Does the operating system support object-oriented software development?

• Is multi-processing (multiple CPU) supported?

•

Does the application need a kernel or a full-blown operating system?

2.6. Robotic Software Systems

Sections 2.2 and 2.3 discussed the mechanical hardware and computer

hardware technology involved in robotic systems. The third technology, a crucial

one, that is required for a successful robotic system is the operational software.

The software constitutes the ‘brains’ of the robot and can also help in balancing

some of the limitations of the mechanical and computer hardware of the system.

The design of the software system also influences the integration cost and the

usability of the robot manipulator. The following sections discuss the three major

layers of robotic systems control software and give an overview of the past and

current research in those areas. The middle layer of robotic software (operational

software) is discussed in greater detail as this research focuses on developing a

software architecture for this layer.

2.6.1. Man-Machine Interface

This is the top-most layer of robotic software and it provides means for

accessing the functionality of a robot. This layer is primarily composed of the

robot programming environment which consists of the robot programming



59

language (RPL) and a graphical user interface (GUI). A majority of work done in

the past in robotics involved the development of RPLs [Banachiewicz,

1986][Blume and Jacob, 1984][Grossman, 1986][Harima and West,

1992][Lozano-Peréz, 1983][Rembold and Blume, 1985]. These languages have

continued to evolve and the level of abstraction provided by them continues to

increase with the advancement in computer technology. This has led to the

evolution of RPLs from simple interpreted languages to structured languages to

languages that support task-level programming. Currently, there is no standard

for robot programming languages. In addition to specifically developed RPL’s,

commercially available general purpose languages have also been used for robot

programming. For example, C, Ada, SmallTalk, and Basic have been used for

robot programming [Cox and Gehani, 1987][Hayward and Paul, 1986][LaLonde

et al., 1987][Mohri et al., 1985][Volz et al., 1983]. Also, graphical interfaces

have been developed on top of robot programming languages to assist in robot

programming [Chen et al., 1992][Kapoor, 1992][Smith, 1992]. Current industrial

robot programming techniques use a teach pendant and a RPL to program a robot.

This technique is cumbersome and requires continuous re-teaching of points by

the operator [Leu, 1985]. Task-level robot programming is an evolving technique

that relies on sensor integration and is based on artificial intelligence. In task-

level robot programming, the robot task is specified at a fairly high level of

abstraction as opposed to manipulator level programming where the robot

program is in terms of robot states [Lozano-Peréz, 1983].

2.6.2. Operational Software

A robot programming language is the top most layer of the robotic

software. The layer of software that actually translates the robot programming

language constructs into actuator commands is called the operational software



60

layer. This layer includes kinematics, dynamics, deflection modeling, criteria-

based decision making, and fault-tolerance. Current industrial robots fail to

implement the operational software layer in its full complexity [Tesar, 1989].

Moreover, the software for current robotic systems is implemented as a closed-

system: a system that does not allow for user modification and extension.

Additionally, as most industrial robots are non-reconfigurable six DOF wrist-

point arms, they have simplified kinematics. As such, most of these robots

implement a closed-form inverse kinematics solution and a simplified dynamics

model. None of these formulations are generalized and scaleable [Tesar, 1989].

Thus, what is needed is an operational software architecture for advanced robots.

This architecture will provide the user with basic building blocks which can

be used to develop control programs for robots. These software components

should be reusable. That is, the components should be general enough to

apply to different robots and also be user modifiable and extensible.

Additionally, these components should be applicable to real-time control and

simulation.

The following sections give a detailed literature review of efforts at

developing robotic software systems. Most of the systems discussed implement

all three layers of robotic software and in general have a nominal operational

software layer.

2.6.2.1. RCCL (Robot Control C Libraries)

The Robot Control C Libraries (RCCL) was a significant effort in the

development of a robot control and programming environment based on a UNIXworkstation and the C programming language [Hayward and Paul, 1986]. The

current implementation of this system includes a world modeler, a trajectory

generator, a graphical simulator, and multiple robot support. However,



61

generalized kinematics, deflection modeling, and support for reconfigurable robot

arms is missing from RCCL. Overall, RCCL is one of the most comprehensive

environments for robotics research, but it lacks in key capabilities such as fault-

tolerance, redundancy, and decision making. From a software point of view,

RCCL is based on structured design and thus does not provide the benefits of

reuse via extensibility, which are the hallmark of object-oriented software. Also,

a major effort in RCCL was spent in modifying UNIX for real-time control.

Currently, most commercially available operating systems already support real-

time extensions.

2.6.2.2. Robot Independent Programming Environment (RIPE)

Current trends exhibit the increasing application of object-oriented

software techniques to the development of robotic systems. Miller and Lennox

[1991] at Sandia National Labs have developed a robot independent programming

environment. This software environment uses C++ as the implementation

language, and has the benefits of modularity, abstraction, and extensibility. This

environment allows for rapid-prototyping of robot workcells and provides the user

with a standard interface with which various robots can be programmed. RIPE

interfaces with robot system controllers at the host level. However, RIPE is a

robot programming environment. It does not provide a framework for robotics

research in the areas such as generalized kinematics, decision making, and fault-

tolerance.

2.6.2.3. Generic Intelligent System Control (GISC)

GISC is an effort by Sandia National Labs at developing an open

architecture for machine control [Burchard and Feddema, 1996]. Based on the

GISC-kit a generic robotic and motion control Applications Programming



62

Interface (API) has been developed. This API provides a generic interface for

command sequences between a supervisory control system and devices ranging

from one DOF motion devices up to six DOF robotic systems. This API can be

used for distributed control. Communication across different platforms (UNIX,

PC’s) is achieved using an object brokerage system (in this case the CORBA

software). The GISC software system further relies on RIPE to interface with

robot system controllers. The combination of GISC and RIPE offers a

sophisticated environment for machine interfacing using the latest in software

technology. However, these systems do not address the operational software

needs of advanced robots. These systems are merely used for supervisory control.

Additionally, GISC and RIPE have been used to interface to standard six DOF

industrial robots. These robots are mechanically constrained and require a

minimal operational software layer.

2.6.2.4. Sequential Modular Architecture for Robotics and Teleoperation

Sequential Modular Architecture for Robotics and Teleoperation

(SMART) is an effort by Sandia National Laboratories at developing a software

environment that supports the building of complex nonlinear digital robot control

systems from modular components that guarantee stability and predictable

performance [Anderson, 1993]. SMART has been applied to projects as diverse

as multi-robot control, flexible robot simulation, kinesthetic virtual reality, and

11-DOF redundant robot control. SMART incorporates over a hundred different

modules that include sensors, input devices, and robots. Modules that include the

computation of kinematics and dynamics are also available.SMART can be used for any robot that can accept external position set

points and with any sensor that can be interfaced to a VME bus. Distinct modules

are defined for each sensor, actuator, input device, and dynamic element. The



63

hardware consists of commercially available CPUs and processor boards running

on a VME bus with a UNIX-based operating system like VxWorks. The system

is connected to a host processor and a graphics workstation by Ethernet. The

software consists of libraries of C routines. The architecture is parallel and real-

time.

From the literature reviewed, it is clear that SMART is the only robotic

software environment that comes close to achieving the goals of the OSCAR

architecture that is being proposed in this research. However, SMART is a real-

time generic control architecture that has some operational software content. This

research will focus on the operational software and develop a reusable

architecture for that purpose. Additionally, SMART is available as a library of C

routines. This implies limited object-oriented capability of SMART.

2.6.2.5. Control Shell

Control shell is a component-based real-time programming system. This

system is based on object-oriented design and it provides components that allow

the building of real-time control systems. Control shell further provides a

graphical environment for assembling the components. New components can also

be created by aggregating the existing components. Reusable components are

provided for PID control, impedance control, and trajectory generation. Control

shell also supports a network transit system. This system uses Ethernet and TCP

sockets for communication [Brain, 1994]. Further, control shell supports run-time

configuration management. This allows the run-time reconfiguration of the

execution structure. For example, a PID controller could be replaced by a PDcontroller to quickly get a comparison. Control shell is based on the VxWorks

real-time operating system [WindRiver Systems] and it bridges the gap between

VxWorks and the real-time application. [Schneider et al., 1994]



64

Basically, control shell addresses all the issues involved in robotic system

level software. However, control shell has a minimal operational software layer.

Support for advanced robotics is completely missing. It does, however provide a

framework for further robotic software development. The operational software

layer being developed as a part of this research could be integrated with control

shell. This would make control shell applicable to advanced robotics.

2.6.2.6. Robot Shell

An effort by Vuskovic et al. [1988] led to the development of a robotic

application-oriented extension to the UNIX shell, called the robot shell. This

provided support for general purpose formulations related to robotics. This

includes homogenous transformation matrices, three-by-three rotation matrices,

vectors, various orientation angle representations, etc. Using the robot shell, the

user could model robotic systems efficiently. However, support for generalized

kinematics, dynamics, deflection compensation, fault-tolerance, etc. was missing.

Moreover, commercial tool-kits can be purchased as extensions to mathematical

software (example Matlab and Mathematica) which provide robotic related

constructs. An advantage of the robot shell is that it provides an interactive

environment. This allows for quick evaluation of results and testing of simple

algorithms. A compiled software environment is better suited for complex

algorithms which have real-time constraints. This is because various

optimizations can be done by the compiler and the user has more control over the

data flow in the program.

2.6.2.7. Design Automation

Effort in mechanical design software has also been concentrated in the

development of new programming languages suited for mechanical design. The



65

latest among this is the CH programming language that is designed to be a

superset of ISO C with incorporation of all the programming features of

FORTRAN 90 [Cheng, 1995]. CH supports metanumbers (-0.0, +0.0, Inf, -Inf,

and Nan) and provides data types for complex, dual, and array. Besides these

features, the language supports polymorphism that allows for different functions

to have the same name with different argument types. Also CH borrows the

syntax of call-by-reference from C++. CH

also supports nested functions which

are beneficial for encapsulation and hence modularity. CH supports automatic

type conversion. An example of this is when a real number is automatically type-

casted to a complex. Automatic type conversion is a serious design issue and is

generally undesirable for robust software development [Coplien, 1994]. However

a controlled use of automatic type conversion can ease the software development

process. C++ is a strongly typed language but it allows the implementation of

automatic type conversion between data types. All the features of CH are

available or can be made available in C++. Nested functions can be represented

in C++ by using block-structured programming techniques [Coplien, 1994]. The

metanumbers can be implemented as data types by encapsulating the underlying

representation of floats and doubles in C++. Also, the complex, dual, and array

data types are rudimentary and are straight-forward to implement in C++. In

addition, due to the object-oriented nature of C++, these data types, when

implemented will have the look and feel of built-in data types to the user.

Moreover, C++ being an object-oriented language, it allows for reuse and

extensibility through dynamic binding, inheritance, and parameterized types

[Coplien, 1994]. A novice does not have to use these advanced features and can

be satisfied by the data types provided. However, an advanced user can extend

these data types, modify them, and create new ones. This capability is essential

for building large scale software systems for intelligent machines.



66

2.6.2.8. Various Object-Oriented Robotic Environments

Tomiyama et al. [1991] were involved in the development of a UNIX-based robot control system. In this, the real-time computations are done on

Motorola 68020 CPU boards on a VME backplane. The UNIX workstation is a

host computer that is used for software development and to provide an interface to

the operator. This architecture is fairly standard and is commonly used in today’s

research environments [Aalund, 1991]. Again, this setup was for one particular

robot arm and the software developed for this endeavor was not generalized

enough to take care of other robot arms.

Object-oriented techniques have been applied to robotics research in

excavation, sensor integration, manufacturing cell control, and predominantly

robot programming and motion planning. Zheng’s [1989] effort at sensor

integration utilizes object-oriented design to create the concept of a logical sensor.

Using this approach, a sensor is modeled at a high level of abstraction as an

abstract data type. This allows for a software architecture which does not change

as sensors are added, removed or modified. The sensor integration takes place in

all three layers of robotic software and does not modify the overall structure of the

software.

Baugh and Rehak [1992] outline the advantages of data abstraction in the

development of engineering software. According to them, data abstraction offers

the advantages of modularity and provides a clean delineation between design and

implementation. Again, object-oriented design languages are proposed as they

best support the linguistics for data abstraction.

Work was done by Bullock and Oppenhiem [1992] in developing an

object-oriented software system for robotics research in excavation. Again the

characteristics of modularity, standardized interfaces and data abstraction that are



67

offered by object-oriented design lead to a computational environment that

supports rapid-prototyping.

All robot manipulators have a definite sequence of steps through which

they are powered-on and powered-off. Cox [1988] used the constructor and

destructor mechanism to develop a robotic software system that supports

guaranteed initialization and safe termination. This leads to a more reliable

system. Additionally, C++ support for exception handling is used for safe error

recovery and termination.

Pimentel [1990] used an object-oriented software architecture for

specifying, designing, coding, and testing software for intelligent automation

systems. This system was primarily for supervisory control of machines and did

not deal with the operational software aspects of the machine (robot).

Nevertheless, object-oriented design led to a more modular and scaleable

environment with standardized interfaces.

Currently, robotics research has focused on using object-oriented software

design to implement robot planning and programming systems. Work done by

Boyer et al. [1991] led to the development of a Dual-Hierarchical Object-Oriented

Design (DHOOD) methodology. This methodology modifies the standard

methodology of object-oriented design (which involves identifying relevant

physical objects and mapping them into object classes) to include support for

concurrency and distributed software systems. Concurrency is important for robot

planning software due to the asynchronous and parallel nature of the physical

environment which the software is supposed to control. The work done by Bison

and Gini [1989] provides an argument for using object-oriented programming for

task-level robot programming. The ability to construct self-contained modules

and to interact with them at a high level of abstraction lends itself to task-level

robot programming.



68

2.6.2.9. Summary of the Operational Software Literature Review

This section discussed some relevant work done in the development of robotic software systems that have some operational software content. It was seen

that most of these systems were developed for standard six DOF industrial robots.

The operational software for these systems supported closed-form kinematics and

simplified dynamics. It was also seen that these software systems were geared

more towards providing a robot programming environment. Issues like

redundancy, fault-tolerance, and decision making were not addressed in the

software architecture. Moreover, none of these systems provided an operational

software architecture that was general and extensible. Object-oriented design was

only used to simplify robot programming (that is, the top most-layer of robotic

software) and to provide a generic software interface to different industrial

manipulators. A summary of the literature review is listed in Table 2.4.



69

Research Summary

RCCL − Based on the C programming language− Uses UNIX for real-time control− Advanced robotics not supported− Based on structured design− Software generality and extensibility missing

RIPE − Primarily a robot programming environment− Uses object-oriented design to provide standard robot

programming interface− Advanced robotics not supported− Developed by Sandia National Laboratories

GISC − Integrates RIPE for robot programming− Works at a supervisory level to the system controller− Uses object exchange for distributed computing−

Does not address operational software needs of systemcontrollers− Developed by Sandia National Laboratories

SMART − System that comes closest to satisfying the goals of thisresearch

− Addresses kinematics and dynamics− Does not seem like a completely generalized architecture− Available as set of C functions.− Limited reuse potential due to lack of object-oriented

architecture− Developed by Sandia National Laboratories

Control Shell − Component-based real-time programming system− Addresses all layers of robotic software

−

Lacks in operational software components for advancedrobotics− Would be ideal for integration with this research

Robot Shell − For non-real-time systems− Does not support advanced robotics− Cannot be used for large-scale systems− Basically a calculator for robotic computations

C H

Programming

Language

− Supports Complex, Dual, and Array data types− Extensibility through inheritance, parameterized types not

supported− C++ is a better choice for developing design software

Other Object-oriented

Robotic Software Systems

− Object-oriented design primarily used to providestandardized interfaces and data abstraction

− Primarily robot programming and integration environments− Research basically stresses the advantages of object-

oriented design for machine control software

Table 2.4: Summary of Robotic Software Systems.



70

2.6.3. Real-time Layer

The real-time layer is the lowest layer of robotic software at the systemlevel. This layer is responsible for sending the position, velocity, or acceleration

commands to the actuators, handle external and internal events in real-time,

interface with external hardware devices and also interface with the operational

software layer. As this layer handles a number of concurrent tasks, a parallel

execution environment is best suited for this layer. Also, it is preferable to use a

real-time operating system for this layer as the desired latency to handle an event

may be very small (less than one millisecond). As this layer is based on parallel

software execution, different inter-process communication schemes can be used

for communication between concurrent tasks. The two predominant schemes are

message passing and shared memory [Silberschatz and Gahin, 1994]. Generally,

the selected scheme is dependent on the operating system being used. Work done

in this area by Rubin [1993] led to the use of the black-board (based on shared

memory) scheme as a means of software organization.

Stewart et al. [1991] also proposed and implemented a framework for

integration of real-time software modules for reconfigurable systems. This effort

was aimed at the lower level control software and provided an efficient technique

for sensor integration. This effort used structured design and was built on the

CHIMERA real-time operating system.

As mentioned above, the real-time layer interfaces with external hardware

and the actuator controllers. These actuator controllers are embedded within the

actuator casing. For an advanced actuator, these controllers will have to support

software for multiple sensors, sensor-data reduction, communications, fault-

tolerance, system-modeling, motion control, etc. Tesar [1996] outlines some of

the details regarding the design of advanced actuator systems.



71

2.7. Impact of Advancement in Computer Technology

Computer technology has seen unprecedented growth in the past few

years. This has resulted in the availability of 400 MFLOP performance from

desk-side uniprocessor computers. This performance level, only a few years ago,

was the sole domain of super-computers [Hernandez et al., 1989]. Hernandez et

al.’s [1989] report on computational requirements for advanced robots predicted

0.6 MFLOP performance from personal computers in the year 1995. This

currently (1996) is around the 15 MFLOP level (Intel 100 MHz Pentium) and is

expected to reach 800 MIPS by the year 2000 [Lewis, 1994]. Also, theperformance ratio of the super-computer versus the personal computer was fixed

at 105 [Hernandez et al., 1989]. However, it is noted that this ratio is decreasing

[Lewis, 1994]. Thus, it is seen that the computer performance has increased at an

unprecedented rate belying all predictions. This increase in processor speed has

impacted current software design and programming methodologies, with object-

oriented programming gaining wide acceptance.

Robotics, though a key area that could benefit from the increase in

processor performance, has not seen a similar revolution. It is evident from the

literature, that a major part of robotics research involves developing or modifying

existing techniques for kinematics, dynamics, etc., for computational efficiency

[Izaguirre et al., 1992]. This usually destroys the generality of the software, and

also renders it in-extensible. Robotics research has also focused on designing

new computer architectures that are more suitable for computing mathematical

formulations that are pertinent to robotics [Anderson and Smiarowski,

1991][Butner et al., 1988]. Notable is the effort by Wander [1987] in which an

array processor based on a pipelined architecture was used for real-time

computation of dynamics and deflection modeling. This research showed that it



72

is important to use special purpose hardware to demonstrate concepts: those that

could be implemented on generic computer hardware in the future.

The problem with robotics research in the area of designing fast computer

architectures and modifying existing algorithms for computational efficiency is

that the effort is being spent on a problem that will no longer exist in the future.

This would be due to the advancement in computer technology. An example to

illustrate this issue is presented: Wander in 1987 was able to compute robot

dynamics for a six DOF arm on a specialized and expensive array processor in 5

milliseconds using a laboriously written code. The same performance is now

(1996) possible on a low-cost high-end personal computer using generic software

environments. Nevertheless, Wander’s [1987] research showed what is possible

in the domain of real-time computing. It was not an effort in designing new

computer hardware. Furthermore, Wander’s research validated the research being

pursued at the Robotics Research Group and provided an argument for furthering

this research.

In summary, robotics research needs to progress into new areas, no matter

how computationally complex these are. Also, the research that has been done in

the area of advanced robotics has to be implemented in a generalized and object-

oriented framework that supports portability, reuse, and extensibility. Such a

framework can grow as research progresses, and it in itself could be instrumental

in spurring robotics research.

2.8. Desired Characteristics of the Software System

The historical perspective presented in the previous sections concentrated

on the evolution and development of mechanical hardware, computer hardware,

and software technologies associated with robotics. The discussion noted that a

major part of the robotic system is software. Robotic software was presented as



73

consisting of three layers: the middle layer (operational software) involved

kinematics, dynamics, deflection modeling, decision making, and fault-tolerance;

the upper layer involved the robot programming environment; and the lower layer

involved the real-time control layer. From the literature review it was noted that a

considerable amount of work has been done in the development of robot

programming and low-level robot control software. All of the systems reviewed

in the literature had a rudimentary operational software layer. Additionally, it was

seen that object-oriented design was gaining popularity as a software design

technique for intelligent machine software. It was also seen that one area of

robotic software that needed further development was the operational software

layer. That is, the layer that implements the fundamental mathematical constructs

associated with high performance robot arms. A complete software architecture

for this layer needs to developed. This architecture should support software reuse,

which can be achieved via generality and extensibility.

Figure 2.13 depicts the structure of the two lower layers of robotic

software. These are, the operational software and the real-time control layer. The

figure depicts the generalized nature of the operational software components

which support kinematics, dynamics, deflection modeling, and performance

criteria. The output of these components can be channeled to a simulation or to

any physical robot through a real-time control layer.



74

D namics

ForcesTorquesInertia

Criteria Compliance

W


Components

To Simulation

Kinematics

Real-Time Control

Components

Performance

Actuator Control

Resource

AllocationOperator Priority Setting

Figure 2.13: Desired Functionality of the Operational Software Layer.

Thus, what is needed is a reusable operational software architecture which

is built on a framework of generalized kinematics, dynamics, deflection modeling,

performance criteria and criteria fusion. This architecture should be equally

applicable to real-time control and simulation. The architecture should be



75

composed of high-level software components with standardized interfaces and an

abstracted functionality. These components should be general enough to apply to

any serial robots and also should support reuse via extensibility. This software

architecture should decrease robot control program development time by 50% as

compared to robotic software systems that are currently in use. Additionally, the

development of the architecture should include the selection of the development

and execution environment, the simulation environment, the software design

methodology, the programming language and the physical robotic hardware for

testing the software.

2.9. Generalized Kinematics

Closed-form inverse kinematics can be used for computing the inverse

solution for a fully constrained robot. Fully constrained robots are those whose

number of joints is equal to the number of constraints at the end-effector. For

example, a six-jointed spatial robot is fully constrained as its number of joints is

equal to the number of independent directions the end-effector can move in (three

translations and three rotations).

Redundant robots have more joints than the number of constraints at the

end-effector. As such, the inverse kinematics solution for redundant arms leads to

an infinite number of solutions (as the system is mathematically non-square).

Numerical solutions are used to compute the inverse kinematics of redundant

arms.

Closed-form inverse kinematics solutions offer the advantages of

robustness and computational efficiency over numerical solutions. Numerical

solutions offer the advantages of reconfigurability and generality. Generality of

an inverse solution is an important issue for modular robots which are field

reconfigurable. Real-time reconfigurability of the inverse kinematics solution is



76

of importance when there is a possibility of change in the robot geometry while

the robot is operational. This change in geometry of the robot may be due to a

faulted actuator. Additionally, the actuator may fail at any position, so there can

be no pre-planned inverse kinematics solutions. For a serial robot to counteract

joint failures it has to support level III fault-tolerance. Level III fault-tolerance

imparts redundant DOF to a serial robot [Sreevijayan and Tesar, 1993]. These

redundancies are used to counteract the effects of joint failures. Under normal

operation, the same redundancies are used for criteria-based performance

maximization. Thus, a generalized inverse kinematics scheme should support

criteria-based performance maximization under normal operation and should also

be reconfigurable in real-time in the event of a fault.

Extensive work has been done in the area of generalized kinematics. The

various approaches taken by researchers are detailed by Hooper [1994]. Some of

these include the Newton-Raphson numerical method, the Predictor-Corrector

numerical method, and the resolved-rate motion control using the Jacobian

inverse. Hooper [1994] discusses the strengths and limitations of these

techniques. Based on this analysis, a generalized inverse kinematics scheme that

incorporates multiple criteria is proposed by Hooper [1994]. This scheme uses

the direct-search technique for computing the inverse position solution. This

technique de-couples the application of performance criteria from the inverse

position solution and is discussed in the following sections.

2.9.1. Direct-Search Formulation

Hooper [1994] developed a generalized inverse formulation that wasbased on using the direct-search technique. The direct-search uses local

explorations in the joint-space of the robot to search for the inverse kinematics

solution. Each time a joint-space exploration is generated, the forward position



77

solution is used to see whether the exploration moves the robot hand closer to the

desired position. The process of exploration generation and checking the

closeness of the hand to the desired hand location is repeated till the desired hand

location is reached.

Hooper [1994] made enhancements to the direct-search technique to

incorporate criteria-based decision making. In this case, Hooper uses a six DOF

sub-structure of the redundant arm to satisfy the end-effector constraints. The

remaining joints are used to generate null-space options. A criteria-based

decision making scheme is then used to rank all the options. Currently, Hooper

uses a closed-form inverse solution for the six DOF sub-structure inverse. The

incorporation of the closed-form solution breaks down the generality of the

inverse. For details on Hooper’s [1994] work see Chapter Three.

This research will design a generalized inverse scheme that can offer some

of the advantages of the direct-search technique, and yet is computationally

efficient and reconfigurable in real-time for use in fault-tolerance. This can be

made possible by using a numerical solution for solving the inverse position

solution for any six joints sub-structure of a redundant arm, and using the direct-

search technique for generating null-space options using the remaining joints. By

allowing the ability to pick any six joints and also allowing the capability of

changing the set of six joints, computational efficiency, criteria-based

optimization, and generality can be achieved.

2.10. Summary

All mature industries are characterized by the presence of a component

industry. An example of this is the automobile industry that is supported by a

large base of ancillary industry. Also, the personal computer hardware industry

has a distinct component industry. Surprisingly, the component industry is barely



78

present for the major U.S. industry of software. This lack of a component

industry is even more noticeable in the arena of intelligent machine software.

However, there is a growing software component industry mainly due to the

popularity of object-oriented design. Object-oriented design allows the building

of software components with standardized interfaces and reuse capability. This

reuse is achieved by generality and extensibility.

Under robotic software systems, it was seen that none of these systems

implemented all of generalized kinematics, dynamics, deflection compensation,

and decision making (see Chapter One). Moreover, object-oriented design was

only used to provide better robot programming interfaces [Miller and Lennox,

1991]. In addition, most of these systems were implemented keeping in mind the

scarcity of computer resources and limited CPU power. This constraint made

these systems excessively specific and in-extensible.

Availability of cheap computer power will be a key factor in the design of

future machines. Thus, it is necessary to research robotic software systems with

an awareness of the state-of-the-art in computing. Currently, advanced UNIX

workstations offer 400 MFLOP performance. This performance level is sufficient

to implement full dynamics, kinematics, deflection modeling, and some criteria-

based decision making [Hernandez et al, 1989]. Also, the gap between personal

computers and workstations is decreasing. It is predicted that the performance of

a personal computer will increase ten times by the year 2000. This will lead to

desk-top personal computers capable of 800 million-instructions-per-second

(MIPS) [Lewis, 1994]. Currently, this performance is offered by the most

advanced workstations and low-end super-computers. This prediction for

computer technology has a definite impact on this research. With a decrease in

the price-performance ratio of computer hardware, software will be the

commodity that will be more expensive than hardware. This will force



79

researchers to develop generalized algorithms using the latest in software design

and engineering methodologies: methodologies that promote reuse and

extensibility.

Thus, what is needed is a software and hardware environment that fully

exploits the breakthroughs in computer hardware and software technology. This

environment should provide the robotics researcher with a system that is built on

a framework of generalized kinematics, dynamics, deflection modeling, criteria-

based decision making, and fault-tolerance. This system should also support a 3D

graphic modeling environment that allows for visualization and demonstration.

The software for this environment should be developed using object-oriented

methodology, thus providing a path for reuse and extensibility. This software

architecture should show improvements in ‘ease of use,’ generality, organization,

‘time to code,’ and ‘time to test’ over software systems for advanced robotics that

are currently in use. Moreover, this software should be equally applicable to real-

time control. The user should be able to divert the output of this software from a

graphical environment to an actual hardware environment with minimal effort.



80

Chapter Three

3. Performance-Based Hybrid Generalized Inverse

3.1. Introduction

The goal of this chapter is to discuss the enhancements that were made in

this work to Hooper’s [1994] generalized inverse kinematics scheme. First the

basics of inverse kinematics are discussed. Then the details of the direct-search

technique are discussed. This discussion includes the modifications that were

made by Hooper [1994] to achieve a practical implementation. Based on thisdiscussion, the strengths and weaknesses of Hooper’s [1994] scheme are

analyzed. This chapter then focuses on the hybrid formulation that was developed

to overcome some of the limitations of Hooper’s [1994] scheme. This chapter

also discusses a preliminary scheme for criteria fusion and addresses its

limitations. Finally, an example application is developed using this scheme. The

key characteristics and results of this application are discussed.

3.2. Inverse Kinematics

Inverse kinematics is an age old problem that almost all living beings

solve everyday. Every time a human locates his hand, he calculates the angles of



81

his elbow, shoulder, and wrist that are necessary to achieve the desired hand

location. This is the inverse kinematics problem. In the case of robots, it is

necessary to compute the various joint displacements of the robots that are

necessary to achieve a desired hand position and orientation (henceforth position

and orientation will be collectively referred to as pose). The position of a robot

end-effector in three dimensional space can be specified by the X, Y, and Z

Cartesian coordinates. The orientation of the end-effector can be specified using a

set of three angles. These angles can be any of the twelve fixed-angle sets or any

of the twelve Euler-angle sets. The reader should refer to Craig [1986] for details

on orientation representations.

For serial robots, various techniques for solving the inverse kinematics

solutions have been offered by researchers. The foremost of these is the closed-

form inverse kinematics solution [Duffy, 1980]. The closed-form solution relies

on algebra and geometry to come up with equations that can be used to solve the

inverse kinematics solution. For example, consider the three DOF robot shown in

Figure 3.1. The end-effector constraints of this robot are specified by the Xh and

Yh Cartesian coordinates and by θ h, which specifies the orientation of the hand.

Y

Xh ,Yh ,θ h

θ 1

θ 2

θ 3

L1

L2

L3

Figure 3.1: A Three DOF Planar Robot.



82

For the robot shown in Figure 3.1, the closed-form inverse position

solution should solve for the joint angles θ 1, 2,

and3

given the input hand

pose specified by Xh, Yh, and θ h. The closed-form equations for the inverse

position solution can then be formulated as,

θ 11

2 2 2

2=− ± + −

−

−tan A A B C

C B, where

A L Y Lh h= −2 1 3( sin( )) , B L X Lh h= −2 1 3( cos( )) , and

C L L X L Y Lh h h h= − − − − −22

12

32

32( cos( )) ( sin( ))θ θ .

θ θ θ

θ θ 2

1 3 1 1

3 1 1

= − −− −

−tansin( ) sin( )

cos( ) cos( )

Y L L

X L L

h h

h h

, and

3 = h .

Analyzing the closed-form formulation shown above, it is clear that

closed-form solutions are specific to a robot’s geometry. Closed-form solutions

have been formulated for six DOF spatial robots [Craig, 1986]. Another means of

solving the inverse kinematics is using a generalized numerical solution. A

generalized solution is independent of robot geometry and has greater

computational requirements. Numerical solutions are also used for redundant

arms as closed-form solutions are not possible for them. Redundant robots are

those arms that have more DOF than the end-effector constraints. The robot

shown in Figure 3.1 has three DOF and three end-effector constraints and hence is

a non-redundant robot or a fully constrained robot. Spatial robot arms have a

maximum of six end-effector constraints. Thus, if a spatial robot has more than

six joints, it is considered a redundant arm.

Redundancy is used in robot arms for two reasons: increased performance

and fault-tolerance. Unlike fully constrained arms, the inverse kinematics of a

redundant arm has infinite solutions. The availability of infinite solutions for



83

redundant arms can now be used for performance maximization. Thus, from a

given set of solutions (that satisfy the same end-effector constraints), one solution

can be selected that best satisfies some input criteria. Additionally, more than one

input criteria may be present. In this case, intelligent decision making has to be

performed for criteria fusion and normalization.

The other advantage of redundancy is fault-tolerance. Level III fault-

tolerance has been defined by Sreevijayan and Tesar [1993] as the availability of

redundant joints in a serial robot arm. Such robots can use their redundancy to

counteract joint failures. For example, if a ten DOF (four redundant joints) spatial

arm has a joint failure, it still can operate using nine DOF.

Thus, what is needed is an inverse kinematics scheme that applies to

redundant robots and actively uses redundancy in the mechanical structure. This

scheme should be general enough to apply to all possible robot geometries.

Additionally, under normal operation this scheme should maximize performance

based on input criteria and in the event of a fault should use the redundancy to

counteract the fault. To support fault-tolerance, the scheme should be

reconfigurable in real-time without human intervention.

Various generalized inverse kinematics schemes have been proposed by

researchers. One of these is the direct-search technique proposed by Hooper

[1994]. This scheme allows for efficient incorporation of multiple criteria and

supports Level III fault-tolerance. The following section discusses this scheme in

more detail.

3.3. Direct Search TechniqueHooper’s [1994] scheme uses a direct-search approach that is based on

using the forward position solution to search for a suitable inverse position

solution. This technique is then extended to redundant robots and the inclusion of



84

multiple criteria. In the most basic sense, direct-search is a numerical method for

solving equations by using a set of trial solutions to guide the search. The search

is direct because it does not explicitly evaluate derivatives as do gradient and

high-order numerical methods. The direct-search technique begins by an estimate

of a solution, which serves as a base point. From this base point, local

explorations are made. From amongst the local explorations, a new base point is

picked which reduces the error in the solution. This process continues until the

search, at least a successful one, finds a solution. [Hooper, 1994]

The direct-search technique when applied to serial robots involves using

the forward position solution to guide the search. The input into the direct-search

formulation is a desired hand location of the end-effector. The output from the

direct-search is the joint angle solution that will achieve the desired hand location.

The steps for solving the inverse kinematics solution are as follows:

1) Pick a starting joint angle configuration of the robot. This will be the base

point of the search.

2) The next step is to perform a local exploration around the base point. The

idea here is to generate enough options. That is to generate a set of joint angle

configurations. This is done by simulating perturbations in the joints of the

robot. Mathematically, perturbing the joint displacements a small amount,

∆ , from their current values, θ , generates a set of local configuration

options:

θ θ θ θ ∧ ∧

= + ∈: ∆ 3.1

where ∈ is an arbitrary sweep vector with all elements equal to ± 1 or 0. The

vector of current displacement values, , is the base point for perturbations.

At the base point, ∈= 0 . All other ∈ with elements equal to combinations of

± 1 and 0 generate other options. Based on the selection of ∈, a different



85

number of options can be generated. Three strategies for generating these

options are identified by Hooper [1994]. These are simple, factorial, and

exhaustive. [Hooper, 1994]

Simple exploration involves perturbing only one joint displacement at a

time. This exploration pattern finds the individual influence of each joint on

the end-effector motion at any given base point during the search. The simple

exploration explores only a limited portion of the locality around the base

point and thus is computationally efficient The factorial exploration pattern

consists of all combinations of perturbed joint displacements and is based on

factorial design principles. As this scheme explores more options it is slower

than the simple option. The exhaustive exploration guarantees a local

minimum by exploring in every possible direction. As such this scheme is

computationally the most intensive. [Hooper, 1994]

These three exploration patterns correspond to points on the faces, edges,

and vertices of a hypercube with the current base point at its center. Each

point represents a trial solution and the dimension of the hypercube is equal to

the robot’s DOF. Figure 3.2 shows this hypercube for a three DOF robot. The

points on the faces of the cube correspond to the options generated by a

simple exploration. The points on the vertices correspond to the options

generated by a factorial exploration. All these points combined represent an

exhaustive exploration [Hooper, 1994].



86

3) The next step after generating various joint configurations is the selection of a

configuration that moves the robot hand closer to the desired position. This

joint solution is then made the next base point and steps two and three are

repeated. The algorithm iterates until a joint solution is found which satisfies

the error bounds.

The direct-search technique described above works for redundant and non-

redundant robot arms. The next step is the incorporation of multiple criteria in the

inverse position solution. This problem is solved by using six joints of a

redundant robot to satisfy the end-effector equality constraints. The remaining

joints are used to generate joint-space options. These options now constitute the

null-space of the robot. If a physical robot is made to go through these options it

will be seen that the end-effector will remain stationary despite the movement in

robot joints. This is called self-motion. Figure 3.3 shows the simulation of a

+ ∆θ 3

− ∆θ 3

Joint One

Joint Two

Joint Three

+ ∆θ 1− ∆θ 1

− ∆θ 2

+ ∆θ 2

Figure 3.2: A Hypercube Representing the Explorations for a Three DOF

Robot [Hooper, 1994].



87

seven DOF undergoing self-motion. The end-effector is seen to remain stationary

while the joints are moving.

Once a set of self-motions is generated, criteria can be used to rank the

different elements of this set. Based on the ranking, a joint configuration can be

selected which best satisfies the input criteria.

Thus, in brief, Hooper’s [1994] technique for criteria-based inverse

kinematics relies on generating a set of self-motions using direct-search and then

ranking these options based on input criteria. The option that best satisfies the

criteria is the inverse position solution.

To improve the computational efficiency of this inverse kinematics

scheme, Hooper [1994] used a closed-form inverse position solution for a six

DOF sub-structure of the redundant robot. The six joints of this sub-structure are

used to satisfy the end-effector constraints. The remaining joints are perturbed to

generate a set of self-motions. Again, the number of options generated depends

End-Effector

Stays Stationary

Various Joint-

Space Options

Figure 3.3: Self-Motion of a Redundant Arm.



88

upon the type of search (simple, factorial, exhaustive). The generated options are

then ranked based on the input criteria. For example, for a seven DOF robot, a set

of six joints are picked that have a closed-form inverse position solution. The

closed-form solution is then formulated for these six joints and for the remaining

seventh joint, simulated perturbations are used to generate options. Figure 3.4

illustrates the direct-search technique that incorporates a closed-form inverse

solution and decision making. The next two sections discuss the strengths and

weaknesses of this technique.

Input Hand Position


(Rank all options based onmultiple input criteria)

Inverse Solution

(Choose best option)

Generate Options

Closed-form 6-DOF

Inverse Position Solution

(Satisfies End-EffectorConstraints)

Direct-Search on Free Joints

(Explorations: Simple, Factorial,or Exhaustive)

Figure 3.4: Inverse Kinematics Using Direct-Search and a Closed-Form

Inverse Position Solution.



89

3.3.1. Strengths

The previous section described the direct-search technique for solving theinverse position solution of serial robots. The various strengths of this technique

are:

• It is based on the forward position solution. As such, there is no explicit

evaluation of derivatives and thus the inverse scheme is stable at singularities.

• It offers a completely generalized solution when a closed-form inverse is not

used for a sub-structure of the serial robot.

•

The incorporation of multiple criteria is decoupled from the solution of theinverse position solution.

• A fully generalized direct-search technique supports level III fault-tolerance.

Thus, if there is a joint failure, the failed joint is simply made unavailable for

simulated perturbations.

3.3.2. Weaknesses

The weaknesses and possible areas for improvement of Hooper’s [1994]

formulation are stated below:

• The completely generalized direct-search formulation is computationally

inefficient. Real-time implementation of this scheme on current computer

hardware is not possible.

• Hooper achieved a practical implementation of the direct-search technique by

using a closed-form solution for a six DOF sub-structure of the robot. This

makes the formulation computationally efficient but breaks down the

generality of the solution. Additionally, Level III fault-tolerance cannot be

supported under this scheme. This is because the closed-form solution will

fail if a joint that is part of the six DOF sub-structure fails.



90

As an extension to Hooper’s [1994] work, a generalized inverse scheme

needs to be designed that can offer some of the advantages of the direct-search

technique, and yet is computationally efficient and reconfigurable in real-time for

use in fault-tolerance. This can be made possible by using a numerical solution

for solving for any six joints of a redundant arm, and using the direct-search

technique for the remaining joints. By allowing the ability to pick any six joints

and allowing the capability of changing the set of six joints, computational

efficiency, criteria-based optimization, and generality can be achieved.

3.4. Hybrid Formulation

As mentioned earlier, Hooper’s technique of using a closed-form solution

for a six DOF sub-structure of a redundant arm is not generalized and

reconfigurable. One way of overcoming this limitation is to use a generalized

inverse solution for the six DOF sub-structure. Figure 3.4 illustrated Hooper’s

scheme that used a closed-form solution. The hybrid scheme that uses a

generalized six DOF inverse, supports multicriteria decision-making and fault-

tolerance, is shown in Figure 3.5.



91

Figure 3.5 illustrates the hybrid algorithm for the performance criteria-

based generalized inverse. A key advantage of this formulation is the modularity

of the algorithm. In the current implementation, the decision-maker picks any six

joints of the redundant robot arm. These six joints are then passed on to the

generalized inverse solution. It should be noted that any six joints can be picked,

and if that sub-structure is singular, another set of six joints can be tried. As an

improvement to this algorithm, the picking of a six jointed substructure can be

based on selecting a set of six joints that form the most well defined structure that

is furthest from singularities. To support fault-tolerance, the decision-maker also

takes into account the status of all the joints. A joint failure is reported to the

No Solution (singularity)

Input Hand Position


(Rank all options based onmultiple input criteria)

Inverse Solution

(Choose best option)

Generate Options

Fault-Detection andIdentification

Faulted-Joint

Solution

Generalized 6-DOF Inverse

Position Solution (SatisfiesEnd-Effector Constraints)

Decision-Maker

Pick any Six non-faulted Jointsfor Generalized Inverse

Direct-Search on Free Joints

(Explorations: Simple, Factorial,

or Exhaustive)

Figure 3.5: Hybrid Formulation for Generalized Inverse.



92

decision-maker by the fault detection and identification sub-system. Once a joint

has failed, it is rendered unfit for use in the generalized inverse and for option

generation by direct-search.

The generalized inverse solution receives a set of six joints from the

decision-maker. The generalized inverse then uses these six joints to satisfy the

end-effector constraints. If in the process a singularity is encountered, the

decision-maker is informed and another set of six joints is picked and the process

repeated. After the end-effector constraints are satisfied, the direct-search sub-

system is informed. This sub-system then generates various joint angle options

that all satisfy the desired input hand location. The option generation may take

place using any of the three exploration patterns that were mentioned earlier. It

should be noted that the option generation takes place in a loop with the

generalized inverse. Every time a joint is perturbed, the geometry of the six DOF

sub-structure in use by the generalized inverse changes. In essence, the generate

options sub-system generates a set of self-motions of the robot arm around the

base point. This set of self-motions (or joint-space options) is then passed onto

the performance criteria sub-system. The performance criteria sub-system ranks

these options based on the criteria. The highest ranking option is then chosen as

the solution.

3.4.1. Generalized Inverse Scheme

As mentioned earlier, the hybrid scheme uses a generalized inverse for a

six DOF sub-structure of the robot. Thus, it was a key part of this research to

select and develop a generalized inverse scheme that could be used for thispurpose. The set of requirements for the generalized inverse should include:

• computational efficiency,

• applicability to any six jointed sub-structure of the robot,



93

• robustness, and

•

prevalence and proven use in the research community.The resolved rate motion control inverse kinematics scheme proposed by

Whitney was analyzed for this purpose [Whitney, 1969]. This scheme is velocity-

based and uses the Jacobian matrix to solve the inverse kinematics solution.

Additionally, this scheme satisfies the requirements of computational efficiency,

and reconfigurability. This scheme is widely used in the research community and

various extensions have been developed to make it robust around singularities

[Nakamura, 1991]. The following paragraphs explain the resolved rate

formulation in detail and also discuss how the scheme is used to compute the

inverse solution for a sub-structure of a serial robot.

The forward position solution for a serial robot involves calculating the

end-effector position and orientation based on the joint position of the arm. This

is mathematically represented as:

x = f(q) 3.2

where x is the hand position and orientation of the robot and q is the vector of

joint displacements. The inverse position solution involves computing the joint

angle solution for a given hand position. This can be represented as:

q = f (x)−1

3.3

In general, the above formulation is non-linear and there are no analytical

closed-form solutions for a general robot structure. To solve this problem,

differential kinematics based on resolved rate motion control was introduced by

Whitney [1969]. This involves computing the joint velocities based on given end-

effector velocities. This is represented as:

x J q.

=.

3.4



94

Here J is the Jacobian matrix which represents a linear relationship between end-

effector velocities and joint velocities. In addition, the Jacobian matrix is a non-

linear function of the joint positions. Given the Jacobian matrix, the inverse

solution is computed as

q J x.

1.

= − 3.5

Approximating, this can be written as

dq J dx1= − 3.6

The above relation can be numerically iterated upon until the solution for q is

within error bounds. It must be noted that the order of the Jacobian matrix is six-

by-N, where N is the DOF of the robot. The composition of the Jacobian matrix

can be represented as shown below:

J (J J J .. . . . . J )1 2 3w w w w wn= 3.7

where Jwi ∈ R6 implies the ith column vector of the basic Jacobian matrix and is

computed as follows [Whitney, 1972]:

J

z p

z

z

O

wi

^

i 1 ni 1

^

i 1

^

i 1

=

×

− −

−

−

(revolute joint)

(prismatic joint)

3.8

where zi 1

^

− ∈ R3 is a unit vector in the direction of the z axis of the (i -1)th link

frame and pn

i 1− ∈ R3 is a vector from the origin of the (i -1)th link frame to that of

the nth one. The link frames are assigned according to the Denavit-Hartenberg

convention. See Craig [1986] for more details.



95

As mentioned before, the hybrid scheme uses a numerical technique

instead of a closed-form technique to compute the inverse position solution for

the six joint substructure of the robot. This is done by computing the Jacobian

matrix for the six joints that comprise the substructure. Thus, in this scheme the

Jacobian is always of order six-by-six. Based on this Jacobian, the inverse

position solution is calculated by numerical iteration over Equation 3.6. For

example, consider an eight DOF robot for which the inverse position solution is

solved using the hybrid technique. As the robot in question has two redundant

joints, these joints will be used for simulated perturbations. The remaining joints

will be used to satisfy the end-effector constraints using the resolved rate motion

control technique. The algorithm for this can begin with selecting the last six

joints of the redundant arm to comprise the six DOF sub-structure. The Jacobian

is now only computed for the last six joints. The first two joints are

systematically perturbed to generate the joint-space options.

Restricting the Jacobian size to a six-by-six has the advantages of

computational efficiency and the ability to use optimized routines for solving

linear equations. In this scheme, the selection of six joints is controlled by a

decision maker. If there is a joint failure the joint is made unavailable for use by

the numerical solution. Also, if the Jacobian matrix for the selected six joints is

ill-conditioned (condition number through Gaussian elimination), the decision

maker selects another set of six joints. In addition, a singular value

decomposition of the Jacobian matrix can be used to get desired constraint

equations that can aid in the selection of an ideal six joint sub-structure that has

the best condition number.



96

3.4.2. Options Ranking

The output of the option generation part of the hybrid algorithm is a set of joint angle solutions that satisfy the desired end-effector constraints. The next

step is the effective ranking of these options based on input criteria. The

University of Texas Robotics Research Group has put forth a concerted and

systematic effort in developing a set of performance criteria that are relevant to

robot operations. Cleary and Tesar [1990] arranged these criteria into the

following categories: geometric, inertial, kinetic energy distribution, and system

compliance. The geometric criteria are further subdivided into first-order (based

on the Jacobian matrix) and second-order (based on the Hessian array). These

criteria are task independent and based only on the geometry of the robot. The

inertial criteria are based on the dynamic model of forces and torque within the

robot. The kinetic energy performance criteria are based on the overall effective

inertia of the system. The compliance criterion describe the robot’s ability to

perform precision operations under load. The reader should refer to Hooper

[1994], Van Doren [1992], and Browning [1996] for a detailed explanation of the

various performance criteria.

Once a set of performance criteria is available, the next step is the

application of these criteria to the various joint-space options. This is done by

computing the criterion value for each joint-space option and then sorting the

various options based on the criterion value. Figure 3.5 illustrates this process.

The options are represented as a1 , a2 , a3 , ……an-1 , an. The performance criterion

is applied to each of these options and the corresponding criterion value is (c1 , c2 ,

c3 , ……cn-1 , cn) computed. After this, the criteria values are sorted. The end

result is a sorted list of all options.



97

a

a

a

a

a

a

n

n

1

2

3

4

1

M

−

c

c

c

c

c

c

n

n

1

2

3

4

1

M

−

a

a

a

a

a

a

n

n

n

−

−

−

5

4

2

1

4

3

M

Joint Space Options

Performance

Criterion

Sorting

Algorithm

Criteria Values Ranked Options

Figure 3.5: Single Criterion Optimization.

The previous paragraphs discussed the use of a single criterion to rank the

joint-space options. Single criterion optimization provides a basic building block

for redundancy resolution. Though, in almost all “real-world” applications,

multiple criteria would be involved. The presence of multiple criteria complicates

the optimization process. Issues related with criteria fusion and normalization

have to be addressed for successful optimization. Criteria fusion is an active area

of research at the Robotics Research Group.

This research also addresses the issue of criteria fusion. A preliminary

approach to criteria fusion was developed and is discussed. Basically, this

approach relied on the individual ranking of joint-space options for each input

criterion. Thus, the first step in finding the best solution is to rank all the

solutions for each performance criterion in the set of input criteria. Then, based

on the weight of each performance criterion and the ranked solutions for that

criterion, a solution is picked that best satisfies the set of all performance criteria.

This is done as follows:

R w Rt

n

i in

i

m

= ∑=

( )1

3.9

where,



98

n = the number of solutions under consideration,

iw = weight of criterion i,

Ri

n = rank of solution n for criterion i, and

t n R = overall rank for solution n .

An example best explains the formulation in Equation 3.9. Consider the

solution of the inverse position solution of a seven DOF robot. Assume that there

are three input performance criteria, P1 , P2, and P3. Each of these criteria has a

respective weight of w1, w2, and w3. As the robot under consideration has one

redundant joint, the generalized six DOF inverse will be computed for a six jointed sub-structure of this robot. The remaining seventh joint will be perturbed

to generate joint-space options. If a simple exploration is followed, three joint-

space options will be generated. Let these be known as a, b, and c. The process

for multi-criteria optimization now involves ranking the options a, b, and c based

on the individual criterion P1 , P2, and P3. Figure 3.6 shows the ranking of each

option for each criterion. It also shows how the overall ranking for the options is

generated by performing a weighted sum on the individual ranking.

Option Rank

a

b

c

Option Rank

a

b

c

Option Rank

a

b

c

Option Overall Rank

a

b

c

+ + =

P1 , w1, P2 , w2, P3 , w3, Fused Criteria

2

1

3

1

3

2

2

3

1

2w1+1w2+2w3

1w1+3w2+3w3

3w1+2w2+1w3

Figure 3.6: An Example of Criteria Fusion.



99

The formulation shown in Figure 3.6 has limitations. As an example

consider that w1

= w2

= w3

= 1 and a new set of rankings of the options are shown

in Figure 3.7. In this case, as evident from the overall rank in Figure 3.7, it can be

concluded that all the options are equally important, leading to an ambiguity in

option selection. This ambiguity might not be true in the actual physical case.

Criteria normalization is needed to remedy this problem. Criteria normalization

provides a means of comparing criteria values from different criteria. Criteria

normalization can thus provide valuable information that can be used to vary the

weights of individual criteria to achieve meaningful criteria fusion [Browning,

1996].

Another limitation of the average weighting scheme is depicted in Figure

3.8 where only two criteria are used. The overall rank of all three options is the

same. Though in this case it is seen that option a has a rank of three for criteria P1

and a rank of one for criteria P2. Similarly option c has a rank of one for criteria

P1 and a rank of three for criteria P2. Option b, has the same rank (two) for both

criteria. Using the weighted sum technique the overall rank of all the options is

Option Rank

a

b

c

Option Rank

a

b

c

Option Rank

a

b

c

Option Overall Rank

a

b

c

+ + =

P1 , w1 = 1P

2 , w

2 = 1 ,P

3 , w

3= 1

, Fused Criteria

2

1

3

1

3

2

3

2

1

6

6

6

Figure 3.7: Ambiguity in Options Selection - Demonstration of Need for

Criteria Normalization.



100

four. This again leads to ambiguity in the option selection process. Though it is

clear from the individual rankings that option b is the best choice. This is because

option b has the minimum variance over different criteria.

A solution can be offered to the problem shown in Figure 3.8. This

solution is applied only to the ambiguity cases demonstrated in Figures 3.7 and

3.8. The first step of this solution is to compute the variance in the rank of each

option. The option with the minimum variance is then selected as the best option.

For example, in the ambiguity case shown in Figure 3.8, it is seen that the

variance of rank is minimum for option b. Thus, option b offers the best solution.

However, it should be noted that this scheme of using variance to resolve

ambiguity breaks down for the ambiguity example shown in Figure 3.7. In that

example, the ambiguity is evident. If variance is used to resolve the ambiguity, it

is seen that all the three options have the same variance. So the ambiguity still

exists. In this case criteria normalization can be used to resolve the ambiguity.

In summary, a criteria fusion scheme is proposed that uses a weighted sum

of ranked options for each criteria to compute an overall ranking. Each criteria

has an associated weight, determined from the task at hand. Ambiguity can arise

Option Rank

a

b

c

Option Rank

a

b

c

Option Overall Rank

a

b

c

+ =

P1 , w1 = 1 P2 , w2 = 1 , Fused Criteria

3

2

1

1

2

3

4

4

4

Figure 3.8: Ambiguity in Options Selection - Need for Variance.



101

when this scheme is used. This ambiguity is a result of different options getting

the same overall rank. Two steps for resolving this ambiguity have been

proposed. The first step involves computing the variance of the rank of an option

from one criteria to another. The option with the minimum variance is then

selected as the best option. When variance calculation does not resolve the issue,

criteria normalization has to be used to resolve conflicts.

3.5. Example of Hybrid Generalized Inverse

The performance-based hybrid generalized inverse scheme was

implemented using the software components developed as a part of this research.

The hybrid generalized inverse was then demonstrated on a seven DOF robot.

This robot comprised one of the arms of the seventeen DOF dual-arm robotic

manipulator from Robotics Research Corporation. The algorithm was first tested

under simulation and then tested interactively in real-time on one of the arms of

the dual-arm robot.

This demonstration involved the use of a seven DOF arm whose end-

effector was interactively controlled by a six DOF input device. The computation

of the inverse position followed the steps illustrated in Figure 3.5. These are

discussed below for this specific case:

1) Six joints of the seven DOF robot were selected to comprise the sub-structure

for which the generalized inverse was to be computed. These were joints one

and joints three through seven.

2) Joint two was selected for the application of the direct-search. Thus, this joint

was perturbed to generate options. As there is only one redundancy, only

three options are generated.

3) Three criteria were used for decision making and selection of the options.

These are discussed in the next section.



102

3.5.1. Example Performance Criteria

Three performance criteria were used in this example application. Thesewere the distance from a singularity measure, a measure of the joint velocity, and

a joint range availability measure. These criterion are discussed below:

Distance from Singularity

This criterion ranks various options based on the distance from a

singularity of each option. In this case, the measure of transmissibility (MOT) is

used as a measure of distance from a singularity. The MOT can be calculated as,

( )MOT det JJT

= 3.10

where J is the Jacobian matrix. A lower MOT value indicates closeness to a

singularity. Thus, the best option is the one with the highest MOT.

Joint Velocity

This criterion uses the norm of the joint velocities to rank different

options. A measure of the joint velocity is computed by taking an inner product

of the difference between a joint solution and the current robot joint position. The

solutions are then ranked in ascending order with the solution that provides theminimum joint velocity measure (JVM) at the top. The JVM computation is

formulated as follows:

( )[ ] JVM = i icurr i=

n

θ θ −∑ 2

1

3.11

where i is the joint displacement of the ith joint, and icurr θ is the current position

of the ith joint.

Joint Range Availability

Joint Range Availability represents a constraint criteria that tends to

maximize the distance of the robot joints from their physical limits. The JRA is

represented and formulated as follows:



103

JRA =

i i

ii=

nθ θ

θ

−

∑

~

max

2

21 3.12

where i is the joint displacement, iθ

~

is the mid-range displacement and i max is

the displacement at the joint limit. This criterion seeks to select a joint solution

that keeps the joint displacements as near as possible to the midpoints of their

travel.

3.5.2. Example Results

This experiment was conducted using a sample trajectory in which the

robot end-effector was moved 35 cm. in the +X, 22 cm. in the +Y, and finally 35

cm. in the -X direction. The complete trajectory is highlighted in Figure 3.9,

where the left arm of the Robotics Research Dual Arm is pictured during the first

part of the trajectory (+X travel).

X

Y

Figure 3.9: Left Arm During a Section of the Experimental Trajectory.



104

The plots in Figure 3.10 to Figure 3.12 indicate the variation of the best

overall solution (best solution for all criteria) and the best solution for each

criterion along the whole trajectory. The plot in Figure 3.13 gives the variation in

the ranking of the overall best solution for each criterion along the whole

trajectory. The best solution receives the rank 0, and the worst solution receives

the rank 2. The weights for each criterion are all taken to be one. The plots

shown in Figures 3.10 to 3.13 were generated by Murat Cetin.

0 50 100 150 200 2500.75

0.8

0.85

0.9

0.95

1

− overall best solution, −. best solution for MOT

N o r m a l i z e d

C r i t e r i o n V a l u e

Variation of MOT Criterion for the Sample Trajectory

Figure 3.10: Overall Selected Solution and Best Solution for MOT.



105

0 50 100 150 200 2500

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

− overall best solution, −. best solution for JVM

N o r m a l i z e d C r i t e r i o n V a l u e

Variation of JVM Criterion for the Sample Trajectory

Figure 3.11: Overall Selected Solution and Best Solution for JVM.



106

0 50 100 150 200 2500.85

0.9

0.95

1

− overall best solution, −. best solution for JRA

N o r m a l i z e d C r i t e r i o n V a l u e

Variation of JRA Criterion for the Sample Trajectory

Figure 3.12: Overall Selected Solution and Best Solution for JRA.



107

0 50 100 150 200 2500

1

2Ranking of the overall best solution wrt MOT Criterion

0 50 100 150 200 2500

1

2Ranking of the overall best solution wrt JVM Criterion

0 50 100 150 200 2500

1

2Ranking of the overall best solution wrt JRA Criterion

Figure 3.13: Variation in Ranking of the Overall Best Solution along the

Trajectory for Individual Criterion.

Figure 3.13 shows that though there is no significant tendency, the chosen

solution follows the best solution along most of the trajectory for each of the

criteria. Deviations in either one of the criteria do occur in critical regions where

the particular criterion is reaching a minimum or maximum. Differing from usinga linear combination of normalized criteria values, using ranks offers simplicity

and avoidance of trying to minimize the average of unrelated criteria. The “Rank

options” scheme, thus, uses the preference due to the median criterion (as opposed



108

to the average) and is not affected by the outliners (by the magnitudes of the

farthest points from the median) as the linear combination of criteria values

would.

3.5.3. Performance Comparison with Hooper’s [1994] Scheme

This sample demonstration of the hybrid inverse scheme was developed

using the software architecture that is being developed as a part of this research.

The application was executed in real-time on VxWorks and used to control the

left-arm of the KB1207 Robotics Research Dual Arm robot. The application was

also executed in simulation on a SUN SPARC 20-61 running the Solaris

operating system. For the inverse computation in this experiment, an aggregate

error at the end-effector was defined as:

E E E T trans rot = +

where,

E T is the total error,

E trans is the translational error in millimeters,

is the scaling factor,

E rot is the rotational error in radians.

Different values of E T were used to experimentally determine some

operational characteristics of the hybrid scheme. These include the operational

frequency of the inverse solution for real-time control and for simulation. The

results are listed in Table 3.1.



109

Hooper [1994] in his research had conducted a similar experiment using

the direct-search technique on a seven DOF robot. The computation environment

used by Hooper (Indigo R4000 from Silicon Graphics) has an execution speed of

80% of the Solaris environment that was used for simulation mode execution of

the application (see Section 4.2.3 for a comparison of workstations). Hooper

applied the direct-search algorithm using exhaustive exploration. The maximum

translational error used was 0.018 millimeters, a maximum rotational error was0.000029 radians. Additionally, one performance criterion was used. This was

the minimization of joint velocities. The computation frequency of the inverse

was 0.6 Hertz. The computation frequency of this application using the hybrid

scheme and comparable error-bounds was 128 Hertz. Comparing Hooper’s

[1994] results with the results given in Table 3.1, and normalizing them based on

execution environment, it can be safely said that the hybrid scheme offers a

greater than 170-times performance advantage over the direct-search

technique (even though this application used three performance criterion and

criteria fusion as compared to Hooper’s [1994] single criterion application).

Hooper [1994] increased the computation efficiency to about 30 Hertz by

E T ( = 25400) 2.5 0.25 0.025

VxWorks:Real-time computation

with robot in the loop.

12 Hertz 10 Hertz 7 Hertz

Solaris:

Simulation mode.

341 Hertz 282 Hertz 128 Hertz

Table 3.1: Operational Characteristics of the Example Application of the

Hybrid Scheme.



110

incorporating a closed-form solution for the three-jointed wrist of the seven DOF

arm. This step reduced the generality of the solution.

3.6. Summary

An extension to Hooper’s [1994] scheme for criteria-based inverse

kinematics was proposed in this chapter.

This scheme has two steps. First the candidate inverse kinematics

solutions are generated. This is accomplished by a two-level “generate-options”

scheme. The first level is the selection of a full-rank sub-matrix of the Jacobian

matrix and solving for a manipulator configuration to satisfy the end-effector

constraints. The second level involves generating candidate inverse kinematics

solutions around the base configurations found at the first level through the “self-

motion” of the manipulator. After the candidate solutions are generated, the best

solution is selected through the so-called “rank-options” scheme. Within this

scheme, each solution is ranked for each criterion. At the end, the ranks for each

solution in each of the criterion are summed and the solution with the lowest (or

highest rank) is picked as the inverse kinematics solution.

Overall, this redundancy resolution scheme does not promise any local or

global optimalities. However, the modeling of the redundancy resolution in

robotics with this scheme allows better concentration on the multicriteria

optimization aspect.

Thus, once the optimization is freed from the inverse kinematics solution

by generating options using the robot’s self-motion, alternative formulations that

will make use of linear or nonlinear programming techniques can be applied to

the resolution of redundancy in real-time. Further research in this area is currently

being conducted at the Robotics Research Group to overcome the limitations of

this scheme.



111

Chapter Four

4. Development, Execution, and Test Environment

A primary goal of this research was the development of operational

software components for advanced robotics. These components were to exhibit

reuse through generality and extensibility. Additionally, the functionality of these

software components were to be tested on a physical robot and in simulation.

Thus, it was necessary to appropriately select a development, an execution, and a

test environment for the software. The software development environment

includes the computer hardware and software required to develop source code.

This includes the programming language, operating system, software design tools,

and organizational tools. Additionally, pre-made vendor supplied software

components are used to facilitate software development. The software execution

environment includes the computer hardware on which the programs execute and

the operating system the programs use. The test environment includes the

physical robotic hardware the programs control, the simulation computer

(hardware and software), and the peripheral equipment (for example, manualcontrollers) that facilitate robot operation.

Ideally the selection of the software development environment and the

software execution environment should be independent of each other. However,



112

this is extremely difficult to do while remaining practical. The reason for this is

that even though commercial vendors support a wide array of development

environments, the supported environments rarely support all possible execution

platforms (CPU type, computer board type, bus type, etc.). Thus, though a

designer may find the right development environment, the desired execution

environment would rarely be supported. As a part of this research, it was

necessary to resolve these conflicts. The approach taken involved the

identification of required characteristics of the various sub-systems. Based on

these characteristics, the best available sub-systems were identified. Once this

was done, vendors were located who best satisfied the needs of the various sub-

systems that were identified. Iteration was used at this point to resolve conflicts.

The following sections explain the selection process for the software

development and execution environments and their sub-systems. The criteria

involved in the selection process and the options considered are explained.

Finally, the test environment is explained and then managerial and organizational

issues faced in the software development process are outlined.

4.1. Development and Execution Environment Types

A software designer can take two paths while selecting a software

development and execution environment. The path taken affects the cost of the

environment, the complexity of the development process, and the end product.

The following sub-sections explain the two available options.

4.1.1. Self-Hosted Systems

The best way to explain a self-hosted system is through an example. A

self-hosted system is generally what most software developers use for their

software development and execution. A personal computer that is used for



113

programming and for the execution of the program is a self-hosted system. In

other words, a self hosted system offers a development and execution

environment in one unit as illustrated in Figure 4.1. Generally, a self hosted

system is characterized by adequate memory and hard-disk space and a processor

that is fast enough for efficient software development.

Applications that do not have space constraints and thus can support a

“full-blown” computer system should use self hosted systems. The various

advantages of a self-hosted system are:

• They have a higher price/performance ratio. This is primarily because of the

large quantity of these systems in the market.

• The most sophisticated technology in computing is generally first made

available on computers using a self hosted development environment. This

includes the latest in operating systems, CPU’s, and software development

tools.

• The software development process is simpler and the user needs to become

familiar with only one system.The disadvantages of a self-hosted system are:

• The software development tools on the self-hosted system may require more

resources (hard disk, memory, processing power) than what may be necessary

Figure 4.1: A Self-Hosted System.

Software Development

Environment

SoftwareExecution



114

for software execution. This can make the system excessive and render it

unfit for embedded applications.

• In general, only commercially popular software development tools are

available for a self-hosted system. Special purpose tools (real-time operating

systems) are still not widely available on self-hosted systems.

4.1.2. Cross-Development Systems

A cross-development environment requires two separate sub-systems.

These include the software development system and the software execution

system. The software development environment is generally any computer with

enough resources to support software development tools. These include, cross-

compilers, databases, version control software, and others. Software developed in

this environment is executed on the execution environment which in general is

another computer with enough resources for software execution. Figure 4.2

illustrates a cross-development system.

Software ExecutionEnvironment

Software DevelopmentEnvironment

Program Downoladand Debug

Software Development Environment

Software Execution Environment

Program Download and Debug

Figure 4.2: A Cross-development System.



115

The advantages of using a cross-development environment include:

•

A single development environment can be used to develop executableprograms for different execution environments.

• The execution environment can have limited resources and can thus be

packaged compactly. An example of this is the embedded computer in a

microwave oven. The software for this computer is developed on a larger and

better equipped computer. Once the software is developed, an executable

version is then downloaded to the embedded computer.

• Commercially, a majority of real-time operating systems are geared towards

cross-development environments.

The disadvantages of a cross-development environment are:

• Software development tools are more expensive as compared to tools for self-

hosted systems (generally personal computers and workstations). Also, the

state-of-the-art software development tools may not be available for cross-

development environments.

• Cross-development is more complex and is not as integrated as development

for self-hosted systems.

4.2. Development Environment Selection

The software development environment constitutes

• the software design methodology,

• the programming language,

• the software development tools (computer aided software engineering

(CASE), compilers, debuggers, software organization tools, etc.),

• the operating system used to facilitate software development, and

• the computer hardware on which the software is developed.



116

Amongst these, the software development tools have the maximum effect

on the quality of the software. Generally, the computer hardware is selected based

on the availability of software development tools and the price/performance ratio

of the hardware. The following sections discuss the various systems that

constitute the software development environment and the issues involved in their

selection.

4.2.1. Software Design Methodology

Currently there are two predominant software design methodologies.

These are structured design and object-oriented design, with the latter rapidly

gaining in popularity. Functional decomposition characterizes structured design.

In functional decomposition the program is broken down into sub-routines (or

procedures). These sub-routines act as instructions that act on data flowing

through them. As the data goes through the sub-routines, it undergoes

transformations. Generally, programming with languages like FORTRAN, C, and

Pascal constitutes structured programming.

The other software design methodology that was considered was object-

oriented design. Object-oriented design professes the decomposition of the

software using objects. Unlike sub-routines (which just hold instructions), objects

hold instructions and data together. This leads to a very modular and self-

contained design of software components. For example, a matrix object will hold

the elements of the matrix, the size of the matrix, and functionality for inverting,

transposing, and multiplying matrices. Additionally, object-oriented design

promotes software reuse through a construct called inheritance. Usinginheritance, a new object (child) can be created by deriving it from an existing

object (parent). The child object inherits all the functionality of the parent. This



117

inherited functionality can either be modified or even new functionality can be

added. Section 2.5.1.2 provides more details on object-oriented design.

The goal of this research was to develop a reusable software architecture

for advanced robots. This architecture should support modularity and rapid-

prototyping. From literature and experience it was evident that relative to

structured design, object-oriented design offered the advantages of modularity,

encapsulation, standard interfaces, abstraction, reuse, extensibility, and

maintainability (see Section 2.5.2.1 for more details). Because of these

advantages, object-oriented design was chosen as the primary design

methodology for this research.

4.2.2. Language Selection

A computer programming language is a means of describing to the

computer the task to be accomplished. Examples of popular computer

programming languages are C, C++, FORTRAN, Pascal, and BASIC. As a part

of this research, it was necessary to select a programming language for

implementation of the proposed software architecture. The various criteria that

were used in judging different programming languages were:

• Support for object-oriented programming.

• Availability.

• Performance.

• Flexibility.

• Support for low-level and high-level programming.

• Compatibility with other programming languages.

• User preference (developers at the Robotics Research Group).



118

The various programming languages that were considered for this research

included C, C++, Lisp, and Ada. Table 4.1 shows these languages with the

criteria used to evaluate them. The criteria are ranked between zero and five, with

zero meaning the worst choice and five meaning the best choice. Amongst all

these languages C++ was chosen as the implementation language. The primary

reason for choosing C++ was its availability and compatibility with the Cprogramming language. As a large base of C software for robotics was already

available, it was necessary to use a language that could easily incorporate the

existing software. Additionally, users familiar with C can gradually phase

themselves into using C++. Also, C++ supports high-level and low-level

programming as well as C does. Moreover, the availability and cost of C++

compilers and programmers makes it an attractive programming language. C++

also provides the key capabilities and benefits offered by object-oriented

programming without including features that would constrain its use to a limited

set of application domains and environments. The mechanisms are defined for

efficient implementation and an easy migration path for a large amount of existing

LanguageCriteria C C++ Lisp Ada

Object-oriented support 0 4 5 3

Availability 5 4 3 3

Performance 5 4 2 4

Flexibility 5 5 3 3

Low-level Programming Support 5 5 3 4

Compatibility With Existing Software Base 5 5 2 3

User Preference 3 5 1 1

Total 28 32 19 21

Table 4.1: Comparative Analysis of Reviewed Programming Languages.



119

C software and programmers. Features that would result in performance penalties

have not been included in the language. Thus, C++ does not strictly enforce

object-oriented programming [Jordan, 1990]. This is a drawback of C++ but it

can be used to design efficient and deterministic programs. Determinism and

efficiency are required for operational and real-time software.

4.2.3. Operating System Selection

The operating system provides a software interface to access the

functionality of the computer hardware. The selection of the operating system for

the development environment is not critical and it depends mainly on user

preferences, support for software development tools, and the desired computer

hardware. It should be noted that for a self-hosted system the operating system

also provides a software execution environment. In this case the functionality of

the operating system is critical to the performance of the software and is discussed

in the section on execution environment selection (see Section 4.3).

Thus, as far as the selection of an operating system to support software

development is concerned, the relevant criteria are:

• User preference.

• Support for software development tools (compilers, debuggers, version

control, etc.)

• Computer hardware supported.

The two options considered for a software development operating system

were Windows NT and UNIX. Based on user preferences and cost, Windows NT

was a better option. As far as the variety of computer hardware and the support

for software development tools is concerned, it was noted that UNIX was a better

option. As the availability of software development tools was crucial to this

research, UNIX was selected as the operating system for software development.



120

However the availability of software development tools on Windows NT is rising.

If faced with a similar decision in the future, Windows NT may prove to be a

better option than UNIX.

After selecting UNIX as the operating system for software development, it

was necessary to pick a UNIX vendor who offered the best price/performance

ratio and the maximum support for development tools. The various criteria that

were used to select a UNIX vendor were:

• Multi-user environment to allow simultaneous code development.

• Robust system with enough security.

• Built in networking.

• C++ development environment support.

• Graphical software development tools (debuggers).

• Availability of Computer Aided Software Engineering (CASE) tools for

software analysis and design.

• Strong customer support.

• Popularity and user preference.

• Efficiency of the computer hardware.

The various options that were considered for the software development

environments that supported UNIX are shown in Table 4.2. The popularity and

the availability of software development tools is ranked on a range of 1 to 5, with

1 implying the minimum availability and 5 the maximum. The prices shown are

1994 academic prices.



121

Among the various UNIX workstations under consideration (see Table

4.2), it was seen that the uniprocessor SUN workstation offered the best

price/performance ratio and best supported software development tools. Hence it

was selected as the software development environment. This workstation

supports the Solaris (a commercial version of UNIX) operating system.

4.3. Execution Environment Selection

The software execution environment includes the computer hardware on

which the software executes and the operating system this hardware supports forefficient software execution. The following sections outline the details of the

selection process for the operating system and the computer hardware.

Criteria

Workstation

ProcessorSpeed SoftwareDevelopment

Tools

Popularity(ranking) Price(approx.)Dollars

SGI Indy MIPSR4400SC 150 MHz

SPECint92 91.7

SPECfp92 97.5

2 4 8,000

SGI Indigo MIPS R4400150 MHz

SPECint92 86.0

SPECfp92 93.2

2 4 19,000

SGI Power Challenge M

R8000 150 MHzSPECint92 108

SPECfp92 310

2 4 22,750

IBM RS6000

Power Station 3BTSPECint92 114

SPECfp92 205

3 3 22,000

SUN SPARC 20-61Singe Processor 60 MHz

SPECint92 89

SPECfp92 102.8

4 2 11,497

SUN SPARC 20-61Dual Processor 60 MHz

SPECint92 89

SPECfp92 102.8

4 2 13,497

DEC ALPHA

Model 700SPECint92 162

SPECfp92 230

3 3 26,000

DEC ALPHA

Model 900SPECint92 189

SPECfp92 264

3 3 37,000

Table 4.2: UNIX Workstations Considered for Software Development.



122

4.3.1. Operating System Selection

An operating system is the core of present day computers and provides theuser with an environment to manage the low level details of the execution of

software. Some important functions of an operating system are process

management, memory management, and file system management. Popular

examples of operating systems are UNIX, Windows NT, OS/2, etc. Operating

systems provide the software developer with an Applications Programming

Interface (API) which can be used to develop programs that rely on networking,

parallel processing, and graphical user interfaces. The selection of an operating

system was crucial to this research because the proposed software architecture had

to allow for software execution in an operational and simulation environment.

As mentioned in Chapter Two, this research involves developing a

software architecture for the middle, that is, the operational layer of robotic

software. Thus, the operating system should satisfy the requirements for the

operational software layer. Additionally, the selected operating system will also

have to support the development of the lower-most real-time layer of robotic

software and the top-most layer of robot programming. The requirements of these

two layers also must be taken into account as the development of these layers is

crucial to the success of a robotic software architecture. Thus, the demands on the

operating system are characterized by the requirements posed by each layer of the

robotic software. These requirements are:

Robot Programming Layer

• Support for efficient development of a graphical user interface that will assist

in robot programming and operation.

• Networking support for connectivity to other computers that are used for off-

line programming.



123

• Familiarity and user preference.

Operational Software Layer• Support for object-oriented programming.

• Availability of C++ as a programming language.

• Multi-processor support as robot control algorithms can be computationally

complex.

• Support for parallel processing.

• Built in networking (for simulation).

•

Developer’s preference.Real-Time Control Layer

• Support for real-time software execution (that is, minimum interrupt latency

and context switch time between tasks and a priority-based preemptible task

scheduler). For details on real-time software see Section 2.5.2.

• Ease of interfacing the computer hardware with external hardware.

• A parallel execution environment.

For this research it was necessary to select an operating system that

satisfied the requirements of the operational software layer and in the future

would provide an execution environment for the real-time control layer and the

robot programming layer. Various operating systems were considered for the

execution environment. These were, Windows NT, UNIX, and some

commercially available real-time operating systems (see Table 4.3). It was seen

that Windows NT and UNIX satisfied all but the real-time requirement of the

execution environment. However, Windows NT and UNIX do provide a soft-

real-time environment. Soft-real-time environments support preemptive priority-

based task scheduling but do not have deterministic interrupt handling.

Additionally, the interrupt handling latency of soft-real-time operating systems



124

can be excessive for time critical applications. This limitation of Windows NT

and UNIX removed them from the selection process. The remaining operating

systems under consideration were the commercially available real-time operating

systems. Landman [1996] outlines in detail the selection process for real-time

operating systems and gives the characteristics of some commercially available

operating systems. The criteria used for selection of a real-time operating system

are given below. Table 4.3 shows some of the real-time operating systems that

were considered for this research (data collected in 1994).

• Is the desired hardware platform supported?

• What is the interrupt latency time (should be as small as possible)?

• What is the context switch time (time to switch between tasks should be as

small as possible)?

• Are good software development tools available (compilers, linkers, debuggers,

performance analyzers, etc.)?

• Does the operating system support object-oriented software development?

• Is multi-processing (multiple CPU) supported?



125

VxWorks was selected from all the real-time operating systems that

were evaluated. The primary reasons for this were the availability of software

development tools, a strong track record and acceptance in the industry, support

for a variety of computer hardware, a low interrupt latency, and project

deliverable requirements.

4.3.2. Execution Computer Hardware

Once an operating system software was selected for the execution

environment, it was necessary to select the computer hardware for software

execution. This involved selecting the processor and the computer bus that best

supported the execution hardware. Again, the selection of these was done

Criteria

Name

HostPlatforms TargetProcessors C++Support Multi-Processing Price(discount)

VxWorks SUN, SGI,IBM, PC

PowerPC,MIPS,

Motorola

Yes Yes 25,000(60 %)

Lynx OS Self Hosted System386, 486, SPARC, MVME

Yes No 5000(60 %)

PSoS+m.

SUN, SGI,IBM, PC

Intel,Motorola

Yes Yes 25,000(0 %)

OS-9 UNIX, DOS Motorola,Intel

Yes No 2000

RMKIBM

IBM RS6000

Motorola Yes Yes Not acommercial

product

C Executive UNIX, DOS Intel,Motorola,

MIPS

No No 2,500

VRTX SUN, PC,HP

Intel,Motorola

Yes No 17,000(0 %)

Table 4.3: Commercially Available Real-Time Operating Systems.



126

iteratively with the selection of the real-time operating system. First the selection

of the processor for software execution is discussed.

4.3.2.1. Processor

The processor is the core of the computer hardware and is normally called

the central processing unit (CPU). For this research it was critical to pick a CPU

that was computationally efficient and had support for a wide variety of software

development tools. Thus, the relevant criteria for processor selection were:

• Computational power.

• Availability of software development tools (compilers and debuggers).

• A clearly defined growth path.

Various commercially available processors were evaluated for this

research. The key benchmarks that were used to judge processor performance

were the SpecInt92 and Specfp92. The SpecInt92 is a benchmark for the integer

performance of a processor and the Specfp92 is a benchmark for the floating point

performance. The higher the SpecInt92 and Specfp92 are, the faster the processor

is. For this research, the floating point benchmark was given more weight as

floating point computations are inherent to operational software. Table 4.4 shows

the processors that were evaluated as a part of this research.



127

Amongst the various processors evaluated (evaluation done in October,

1994), it was seen that the PowerPC processor from Motorola offered a good

price/performance ratio and a clear growth path. Additionally, a majority of

software development tools were slated for the PowerPC processor. Though at

this point (March, 1996) the availability of the PowerPC and its software

Brand Number Clock Rate(MHz) SPECint92 SPECfp92

INTEL i486DX2 66 32 16

INTEL Pentium 60 58.3 52.2

INTEL Pentium 99 96.8 85.4

INTEL Pentium 166 200 137.9

INTEL PentiumPro 180 287.1 254.6

INTEL PentiumPro 200 318.4 283.2

MOTOROLA MC68040 40 35 23

MOTOROLA MPC6010 50 51 63

MOTOROLA MPC601 100 110 130

MOTOROLA MPC603 80 75 85MOTOROLA PPC604 100 128.1 120.2

MOTOROLA PPC604 133 176.4 156.5

MOTOROLA PPC604 133 176.4 156.5

MOTOROLA PPC604 166 176.4 156.5

MOTOROLA PPC620 66 200 280

MIPS R4000 150 108 310

MIPS R8000 NA 108 310

SPARC MicroSparc 50 26.4 21

SPARC SuperSparc 60 88.9 102.8

SPARC HyperSparc 150 169.4 208.2HP PA7200 120 168.7 269.2

DEC Alpha 21164 350 432.8 602.2

Table 4.4: Benchmarks for Various Processors.



128

development tools has been delayed. The Intel x86 (Pentium, PentiumPro) family

of processors offers another feasible option.

4.3.2.2. Bus Type

A bus is a medium for transmitting signals from one or more sources to

one or more destinations. It can be used for information transfer within a

computer or between computers and peripheral devices. There are two major

types of buses - computer and instrumentation. The computer bus is the internal

bus that connects the CPU to the various I/O devices and other peripherals

contained within a closed system. The instrumentation bus is used to connect

external devices to each other. The instrumentation bus uses addressable or point-

to-point communication. A VME bus is an example of a computer bus, and

Ethernet is an example of an instrumentation bus. [Potter, 1992]

Once a processor for software execution was selected, it was necessary to

select a bus upon which this processor would be located. The selection of the bus

is crucial to the development of an extensible hardware environment. As the need

arises, more computer boards can be added. These can include CPU modules,

digital I/O cards, etc. Additionally, it was essential that when new hardware was

added, it should couple tightly with the existing hardware. This allows for faster

communication amongst the various hardware modules. An example of this is

when a processor card and a digital I/O card are both located on the same high-

speed bus.

The first issue faced in bus selection is determining the type of bus -

computer or instrumentation. If the devices to be connected have their ownembedded control but have to be supervised by another computer or device, it is

better to use an instrumentation bus. However, if the devices are to be directly

controlled by a computer, then it is better to have a computer bus connect directly



129

to these devices. Some of the important factors for bus selection are presented

below and Table 4.5 gives an overview of some of the commercially available

buses [Potter, 1992].

• Do the various devices on the bus have their own embedded control?

• Are the various devices on the bus directly controlled by another computer?

• What is the desired data transfer rate?

• How many devices are to be attached on the bus?

• Is the bus addressable and if so, how many address lines are provided by the

bus?

• Do the software development tools support the bus type?



130

Table 4.5 compares and contrasts various commercially available buses.

The two options for the bus form are backplane and cable. Backplane buses are

usually more expensive but they provide high data transfer rates and are well

suited for real-time applications. These buses also provide easy expandability by

providing slots into which devices can be plugged. The type of the bus

determines whether it is a computer or an instrumentation bus. Computer buses

provide high data transfer rates and are thus used for internal communications and

can also be used to connect external devices in some cases. [Potter, 1992]

Selecting the Right Bus

Key Attributes of Common Computer and Instrumentation BusesSource: Test and Measurement World, February, 1992 [Potter, 1992].

Bus Type Form Common

Platform/Use

Data

Bits

Address

Lines

Transfer Rate

XT Computer Backplane IBM PCs

8088

8 20 bits 800 Kb/s

AT Computer Backplane IBM PCs

80286/386

16 24 bits 1.6 MB/s

EISA Computer Backplane IBM PCs

80386/486

32 32 bits 33 MB/s

MCA Computer Backplane IBM PS/2,

RS/6000

16 or

32

32 bits 40 MB/s

NuBus Computer Backplane Macintosh II,

Quadras

32 32 bits 37.5 MB/s

SBus Computer Backplane Sun

SPARCstations

32 2b bits

(32 virtual)

80 MB/s

TURBO

Channel

Computer Backplane DECstation

5000

32 28 bits

(34 DMA)

98 MB/s

RS-232 Instr. Cable Peripherals,

instruments

1

(serial)

N/A

(2 devices)

1 Kb/s

GPIB Instr. Cable Programmable

instruments

8 8-bits (15

devices)

1 MB/s

VME Computer/

Instr.

Backplane Workstation/

minicomputers

16 or

32

32 bits 40 MB/s

VXI Computer/

Instr.

Backplane Instruments-on-a-

Card

32 32 bits 40 MB/s

MXI Computer/

Instr.

Cable Computer-VXI,

VXI extensions

32 32 bits 20 MB/s

Table 4.5: Overview of Some Commercially Available Buses.



131

As discussed earlier, this research had to select an execution environment

that supported real-time program execution. It was thus necessary to select a

computer bus that could support high-speed communication between different

hardware modules. Additionally, the availability of computer hardware for the

selected bus had to be analyzed. For example, in this research it was necessary to

connect the execution computer to the physical robot servo-control. Thus, it was

necessary that a hardware bus-to-bus adapter be available that would connect the

execution computer bus to the robot bus. Additionally, the selected bus should be

supported by the selected real-time operating system (in this case VxWorks).

Analyzing the various options, VME was chosen as the bus for the computer

hardware.

4.4. Summary of the Selected Environment

As mentioned earlier, the methodology employed for selection of the

development and execution environment followed two steps. The first step was

the selection of the individual sub-systems in the development and execution

environment. The second step was to iterate over the selected subsystems to

resolve potential conflicts. Eventually, an environment was selected that best

supported software development and execution. This environment is summarized

in Table 4.6.



132

Table 4.6 outlines the various decisions made in the selection of the

development and execution environment. The overall setup for this is illustrated

in Figure 4.3.

System Selected System Reasons For SelectionSystem Type Cross-Development ⇒ VxWorks is a cross-developmentsystem.

⇒ Execution hardware can be changedwith minimal changes to thedevelopment environment.

Host Computer SUN SPARC 20-61(Solaris 2.2)

⇒ VxWorks development tools were bestsupported.

⇒ Best price/performance ratio of allworkstations.

Software DesignParadigm

Object-Oriented Design ⇒ Modularity⇒ Extensibility⇒ Standardized interface

⇒ Encapsulation⇒ Rapid-prototyping

Computer Language C++ ⇒ Supports object-oriented programming⇒ Availability⇒ Compatibility with C

Execution Processor PowerPC (604) ⇒ Supported by VxWorks⇒ Clearly defined future path⇒ Computational efficiency⇒ Availability on VME

Execution OperatingSystem

VxWorks ⇒ Hard real-time system⇒ Best support for development tools⇒ Support for fast processors⇒ Project Requirements (suggested by

Department of Energy)Computer Bus VME ⇒ Abundant processor support

⇒ VxWorks support⇒ Availability of bus-to-bus adapters⇒ Abundant supply of various plug-in

cards

Table 4.6: Summary of Selected Systems.



133

Figure 4.3 depicts the cross-development environment that consists of the

SUN workstation as the host computer and the VME rack acting as the computer

bus and the Force CPU 30 (with a Motorola 68030 processor) card acting as the

processor card. The Motorola 68030 processor is currently (May, 1996) being

used due to the delay in the availability of VxWorks support for PowerPC. Thetransition to PowerPC should be complete towards the end of 1996.

4.5. Test Environment Characteristics

An important part of this research was to validate the software

components that were being developed. Thus, it was necessary to select and

develop a test environment in which the software could be executed and used to

control machines. The key characteristics desired from the test environment are

discussed below. Also, discussed are the facilities developed to fulfill the

requirements of the test environment.

Ethernet

SUNWorkstation

(Solaris)

Development Environment

• Cross-Compiler

• Cross-Debugger• Makefiles• Source-Code Control

Processor Card

Execution Environment

• VME Backplane• Additional Hardware Slots• VxWorks Real-Time

Operating System

Figure 4.3: Final Development and Execution Environment.



134

1) Multiple users should be able to develop, execute, and test the software

simultaneously and efficiently.

The Solaris host computer allows for simultaneous software development.

However, only one user can execute software at any given time. This is because

the VxWorks execution environment is not a multi-user environment as it allows

only one user to download and execute code. Additionally, the process for

compiling and executing code on VxWorks is cumbersome and slow as compared

to developing and executing software for the host computer (SUN SPARC

running Solaris). Thus, it was decided to structure the software development in a

manner that would make it feasible to compile and execute on VxWorks and

Solaris. Also, it was desired that this facility not add any complexity to the

software development for the VxWorks environment. Another advantage of

using Solaris, besides simplicity, was that Solaris is a multi-user execution

environment. Software development, execution, and testing can be done

simultaneously by more than one user. However, to develop a software execution

environment for Solaris, the makefiles [Oram and Talbott, 1995] for the

compilation of source code were modified to include the Solaris environment.

Using this environment, the user could create executables for download and

execution on the VxWorks environment or for direct execution on the Solaris

environment. Figure 4.4 illustrates this concept.



135

The one limitation of this environment was that the code could only be

executed in simulation mode on the Solaris environment. This was because the

hardware connection from the SUN workstation to the physical robot was not

developed. Additionally, Solaris is not suited for real-time software execution.

2) The testing environment should support simulation.

The software development cycle can be roughly characterized by three

stages. These are compile, test, and debug. For maximum productivity, it is

necessary to have an efficient test environment. This productivity is significantly

lowered when software being developed is used to control physical robotic

manipulators. This is because the use of a physical robot is expensive, dangerous,

and cumbersome. To increase the efficiency of the test environment, it was

necessary to allow for the integration of a simulation environment. The

simulation environment is even more important when Solaris is used as an

execution environment. As mentioned earlier, this is because the multi-user

execution environment provided by Solaris supports only simulation.

The simulation environment selected for this research involved using

three-dimensional (3D) graphical simulations of robotic manipulators in place of

Development Environment

• SUN Sparc running Solaris

• Multi-User Development• Source Code can be

Compiled for Solaris orVxWorks

Host Computer

C++ Source Code

• Cross-Compiled for

VxWorks Execution• Compiled forExecution on Solaris

VxWorks Execution

• Executes Code Compiledfor VxWorks

• Single-User Execution

Solaris Execution

• Executes Code

Compiled for Solaris• Multi-user Execution

VME Rack

Figure 4.4: Multi-user Execution and Test Environment.



136

physical robots. The graphical simulations were implemented on stand-alone

computers. ROBOCAD, a 3D modular robot modeling software was used to

create the robot models [Hooper, 1990]. Additionally, complex models of robots

that were not possible in ROBOCAD could be implemented using high-level

graphics libraries developed by the author (see Appendix D). These libraries offer

software components for procedural modeling of 3D shapes. Additionally, these

libraries encapsulate the functionality of the window manager and provide a user-

friendly interface for viewing manufacturing cells. The shapes provided in this

library are basic quadrics (cylinders, spheres, etc.), cones, extrusions, and sweeps.

Using these components, complex 3D graphical environments can be modeled.

Various hardware options were offered for the simulation environment. The first

was the use of Silicon Graphics computers. Both ROBOCAD and the graphics

libraries were available on this platform. The authors graphics libraries (see

Appendix D) were also available on personal computers running Windows NT.

Once the simulation environment was in place, the next step was to

provide a communication interface between the execution computer and the

simulation computer. The requirements for the communication interface were:

• high-speed,

• use of existing networks,

• point-to-point configuration,

• easy reconfiguration, and

• availability on different computer platforms (Solaris, VxWorks, Windows NT,

Silicon Graphics).

To fulfill these requirements, Ethernet was chosen as the hardware

medium of communications. Transmission Control Protocol (TCP) sockets



137

[Brain, 1994] were used to develop the software for the communication. The

advantages provided by using TCP sockets and Ethernet were:

• the number of communication channels was practically unlimited,

• Ethernet was available on almost all hardware platforms,

• high-speed communications (10 Mbits/sec),

• no need for separate wiring (used the existing network), and

• communication programs could be moved from one computer to another

without rerouting any cables and with minor source code modifications.

Figure 4.5 illustrates the setup of the testing environment that implements

simulation. This Figure shows both the Host computer and the VME computer as

the software execution environments. The Ethernet connection of these

computers to the simulation computers is also depicted.

3) The testing environment should support physical machines (robots).

Figure 4.5: Simulation Support for Software Testing.

Ethernet

SUN Solaris• Development• Solaris Execution

Silicon Graphics

• SimulationWindows NT

• Simulation

VME VxWorks

• VxWorks Execution



138

The purpose of this research was to design and develop software

components that could be used to control advanced robotic machines. The real

test for these components was in controlling physical machines (robots). Thus, it

was necessary to make available robotic hardware and the corresponding

interfacing software. This interfacing software would provide a substitute for the

real-time control layer (see Chapter Two) of the robotic software. The operational

software components developed as a part of this research communicate with the

physical hardware through this real-time control layer. Also, as the components

developed as a part of this research were to be used for advanced robots, it was

necessary to provide a test environment that included advanced as well as

standard industrial robots.

Currently, three robotic manipulators are available for demonstrations and

testing of the software. The first and the oldest of these is the Puma Mark II 500

Series six DOF manipulator. The operational software layer communicates with

this robot using an RS-232 connection. The other robot used for this research is a

heavy duty T3-786 industrial robot from Cincinnati Milacron. The operational

software layer communicates using an RS-232 with this robot in supervisory

mode. The third, and the most advanced robot available for this research is the

seventeen DOF dual-arm robotic manipulator from Robotics Research

Corporation. This robot arm consists of two seven DOF arms and a three DOF

torso. The operational software layer communicates with this robot through a

real-time control layer. The dual-arm servo-level controller comes equipped with

an interface that can be used to send position, velocity, or torque set-points to the

servos. The computer used for the servo-control of the dual-arm uses Multibus as

the computer bus. Thus, to connect the execution environment (VME rack,

processor card, VxWorks) a VME-to-Multibus hardware adapter was used. Using

this adapter, memory locations on the servo-level computer of the dual-arm robot



139

can be directly accessed by the execution environment. The interfacing software

for this was developed by Rackers [1996]. Figure 4.6 illustrates the setup of the

test environment.

Figure 4.6: Simulation and Physical Robot Support for Testing.

4) The testing environment should include software support for integration

with manual controllers.

The focus of this research was to develop reusable software components

for advanced robots. This did not include supporting integration software for

Ethernet

SUN Solaris

• Development• Solaris Execution

Silicon Graphics

WorkstationWindows NT

Workstation

VME VxWorks• VxWorks Execution

RS-232

High Speed VME-to-Multibus Connection

T3-786 Puma Mark II Robotics Research Dual Arm



140

connecting to peripheral equipment. Then why is the requirement for integration

software for manual controllers placed in the test environment? There are a few

reasons why it was necessary to provide integration software for manual

controllers. These are:

• Manual controllers are an integral part of robotics and are essential for

meaningful teleoperation.

• The integration of manual controllers was important because an environment

was needed to evaluate and test various manual controllers. The core of this

research already provided an environment for controlling different robotic

manipulators. So the next logical step was to make this environment

accessible to manual controllers. Also, if the claims of reusability and rapid-

prototyping capability of the software components were true, the integration

of manual controllers would not involve extensive program development.

• It was realized that a manual controller provided an efficient interface for

controlling the robot as compared to teach-pendant type approaches.

• Due to the object-oriented nature of the software components developed for

this research, it was realized that any new development for the integration

software would be minimal.

Thus, once it was determined that manual controllers should be integrated

into the operational software architecture, the next step was to choose a path that

supported efficient integration. Two options were considered for this. These

were:

1) The manual controllers should plug-in directly to the execution environment,

that is, the VME rack. Once the manual controller hardware is plugged in, the

next step would be to write the software that interfaces with the hardware.



141

This approach is based on a centralized model of control, with the center

being the VME rack.

2) The second approach is to use a separate computer into which the manual

controllers are connected. The software for interfacing with the manual

controllers executes on this computer. A communication link can then be

provided between the manual controller computer and the VME rack on

which the operational software executes. This path follows the distributed

approach, an approach that proposes the use of loosely coupled localized

controllers connected through high-speed communications.

The advantages and disadvantages of these approaches are as follows:

• In the first approach the software execution takes place under VxWorks

providing for better real-time control.

• The first approach provides an integrated environment for the manual

controller software.

• The first approach, that is, the centralized approach goes against the concept

of modularity. The distributed approach uses localized control and thus

provides for a well defined interface.

• The first approach uses VxWorks. As mentioned earlier, VxWorks is a single

user execution environment. Thus, this approach puts more demands on the

available resources.

• The second approach uses a separate computer. This characteristic can be

used to select a computer that has the best price/performance ratio and has

more efficient software development tools.

Considering the advantages and disadvantages of the two approaches, the

distributed approach was selected. The major reason for this was the modularity

of the approach. Also, using this approach, the integration of manual controllers



142

could take place on its own pace without affecting the software development for

this research.

Figure 4.7: Software Development, Execution, and Test Environment.

Ethernet

Silicon Graphics Windows NT

VME VxWorks• VxWorks Execution

RS-232

High Speed VME-to-Multibus Connection

T3-786 Puma Mark II Robotics Research Dual Arm

Ethernet

TeachBallManual Controller

PerForce ManualController

Kraft ManualController

RS-232

Windows NT Personal Computerfor Manual Controller Interfacing

RS-232 Analog I/O Analog I/O

TOS ManualController

SUN Solaris• Development• Solaris Execution

SimulationSimulation



143

A Pentium processor based personal computer was selected for manual

controller integration. This computer supported Windows NT as the operating

system. Windows NT is a soft-real-time operating system as it allows for task-

based programming and supports a preemptible multi-tasking scheduler (see

Section 2.5.2.3 for details on operating systems). The software for

communication between this PC and the VME execution environment used TCP

sockets and communicated over Ethernet. Figure 4.7 illustrates the complete

environment that was developed as a part of this research. It shows the software

development environment, the execution environments, the simulation

environment, the communication system, and the manual controller integration.

The manual controller environment supports four manual controllers. These are

the TeachBall, the Perforce, the Kraft, and the TOS. All the four manual

controllers are six DOF devices. The next section provides more information on

the manual controllers and the other hardware involved in this research.

4.6. Hardware Description

This section discusses the hardware that was used for software

development, testing, and execution. This includes the software development

computer, the execution computer, the robotic hardware, manual controllers, and

the interfacing hardware. All these components are briefly discussed below:

SUN SPARC 20-61

The main purpose of the SUN workstation is software development. The

source code developed for this research is resident on this computer. Along with

the source code, this computer supports the software development environment

(compiler, linker, debugger, source code control). Besides software development,

the SUN workstation is used for software execution in simulation mode. This



144

allows for software testing before it is executed in real-time to control physical

robots. The specifications of this computer are listed in Table 4.7.

Dell Personal Computer

The main purpose of this computer is to interface to the manual

controllers. As mentioned in previous sections, a distributed control scheme was

used for manual controller integration. This PC thus acts as the hub to which all

the manual controllers are connected. Some of these manual controllers are

interfaced through data-acquisition cards and some are connected through serial

ports. This computer is used for software development and execution and it also

supports the OSCAR software architecture that was developed as a part of this

research. The SUN workstation and the Force CPU 30 board communicate with

this computer using client-server software developed as a part of this research.

The specifications of this computer are listed in Table 4.8.

Processor SPARC 20-61

Processor Specifications 60 MHz SuperSPARC.SPECint92 89

SPECfp92 102.8

RAM 64 Megabytes

Hard Disk Space 3 Gigabytes

Operating System Solaris 2.2 (UNIX)

Table 4.7: SUN SPARC 20-61 Specifications.



145

VME ChassisThe VME Chassis provides a backplane bus onto which single board

computers and other hardware cards are plugged. Currently, a Force CPU 30

processor card is plugged in along with three digital I/O boards. Besides these, a

Bit 3 VME to Multibus adapter is plugged in. The specifications of the VME bus

are listed in Table 4.9 and a picture of the VME chassis is shown in Figure 4.8.

Processor Intel PentiumProcessor Specifications 100 MHz.SPECint92 96.9

SPECfp92 85.4

RAM 16 Megabytes


Operating System Windows NT 3.51

Table 4.8: Dell Personal Computer Specifications.

Type 6U

Number of Slots 18

Bandwidth 40 Megabytes/second

Table 4.9: VME Bus Specifications.



146

Figure 4.8: VME Chassis with Plugged in Boards.

Force CPU 30 Card

This is a single board computer that plugs into the VME chassis and isavailable from Force Computers Incorporated. The main purpose of this

computer is the execution of operational and real-time software. This computer

supports three serial ports and a 10 Megabit/second Ethernet connection. Table

4.10 lists the key specifications of this computer. In the future, this computer will

be replaced with another single board computer that supports a PowerPC

processor (preferably PowerPC 604). Currently (July 1996), a PowerPC

processor card is available but the support for VxWorks is in beta development.



147

Bit3 VME to Multibus adapter

This is a bus-to-bus adapter that is used to connect the VME bus to a

MultiBus and is available from Bit3 Computer Corporation. In the current setup,

the VME bus is the computer bus for the execution computer and the Multibus is

the computer bus for the servo-level interface of the Robotics Research Dual Arm

robot. This connector connects the software execution computer with the servo-

level interface of the dual-arm. This adapter consists of two cards connected by a

cable. One of these cards plugs into the VME chassis and the other plugs into the

Multibus chassis that is resident in the dual-arm controller. Table 4.11 lists the

key specifications of this adapter.

Processor Type Motorola 68030, 25 MHz.RAM 4 Megabytes

Operating System VxWorks

Table 4.10: Force CPU 30 Card Specifications.

Cable Length 25 feet

Bandwidth 1 Megabyte/second

Table 4.11: Bit 3 VME to Multibus Adapter Specifications.



148

TOS Manual Controller

This is a six DOF force reflecting manual controller by Teleoperator

Systems (TOS) and is shown in Figure 4.9 All the six joints of this controller are

revolute [Peterson, 1996]. This manual controller is connected to the Dell PC

through data-acquisition cards and interfacing software from National Instruments

[1996].

Figure 4.9: TOS Manual Controller.



149

Kraft Manual Controller

This is a six DOF force reflecting manual controller from Kraft and is

shown in Figure 4.10. All six joints of this controller are revolute. The last joint

is not actuated and thus does not offer force reflection [Peterson, 1996]. This

manual controller is interfaced to the Dell PC via National Instruments data

acquisition hardware and software.

Figure 4.10: Kraft Manual Controller.



150

NASA PerForce Manual Controller

This is a six DOF force reflecting manual controller from Cybernet

Systems Corporation. The first three joints of this controller are prismatic and are

used for position information. The last three joints are revolute and are used for

orientation control. This controller uses two serial ports to connect to the Dell

PC. One serial port is used to output position data and the other is used to read

the forces. Figure 4.11 shows this controller.

Figure 4.11: NASA Perforce Manual Controller.



151

TeachBall

The Teach Ball is a six DOF input device from ISRA Technologies and is

shown in Figure 4.12. Along with the six DOF input, there are eight buttons on

the Teach Ball whose state can be read. The Teach Ball connects to the computer

using an RS-232 connection. Currently, the Teach Ball can be connected using a

serial port to the Force CPU 30 board, the Silicon Graphics, and the Dell PC.

Figure 4.12: The TeachBall Input Device.



152

Silicon Graphics

The main purpose of this computer is to offer a 3D graphics simulation

environment. This computer supports graphics acceleration hardware and

software for efficiently modeling workcells and robots (see Hooper, [1990] and

Appendix D). The SUN workstation and the Force CPU 30 board communicate

with this computer using client-server software developed as a part of this

research. Table 4.12 lists the key specifications of this computer.

Processor MIPS R4400

Processor Specifications 100 MHz.SPECint92 96.9SPECfp92 85.4

RAM 64 Megabytes


Operating System IRIX 5.3 (UNIX)

Table 4.12: Silicon Graphics Specifications.



153

Robotics Research Dual Arm

This is a seventeen DOF dual-arm robot and its main purpose is to provide

a test-bed for the operational software architecture. This robot is Robotics

Research Corporation model KB1207 [Karlen et al., 1990] and is pictured in

Figure 4.13. The robot consists of two seven DOF manipulators and a three DOF

torso. This robot is interfaced to the VME chassis via the Bit3 VME-to-Multibus

adapter.

Figure 4.13: The Robotics Research Corporation Dual-Arm Robot.



154

Puma Mark II 500 Series Robot

This is a six DOF industrial robot from Unimation Robotics [Unimation

Robotics, 1983]. The main purpose of this robot is for testing the applicability of

the software architecture being developed as a part of this research. This robot is

connected to the real-time software execution environment through an RS-232

link using a serial port on the Force CPU-30 computer.

Cincinnati T3-786 Robot

This is a six DOF industrial robot from Cincinnati Milacron Incorporated

[ABB Robotics Incorporated]. The main purpose of this robot is for testing the

applicability of the software architecture being developed as a part of this

research. Soon this robot will be integrated into a manufacturing cell

environment. The VME chassis will be connected to this robot through an RS-

232 serial port interface.

4.7. Organizational and Managerial Issues

The success of large-scale software systems that involve more than one

developer depends largely on the organization and management of the project. As

mentioned earlier, it was the purpose of this research to develop operational

software components for advanced robotics. These components should promote

reuse via generality and extensibility. From experience it was known that these

components would not fulfill their goal of reusability unless they were made

available to software developers in a consistent and organized fashion. Thus, it

was necessary to develop some software development guidelines and to organize

the source code consistently.

The software development guidelines assist the developer in following

consistent coding conventions. For example, it is suggested in the guidelines that

any C++ class that is developed for this research should have ‘RR’ appended to its



155

name. Thus, the Matrix class is called ‘RRMatrix.’ The reader should refer to

Appendix A for more details on the software development guidelines. An

advantage of following these guidelines is that the source code has a uniform look

and feel. Also, the effect of individual idiosyncrasies is minimized.

Once a uniform set of guidelines for code development was in place, the

next step was the organization of the source code. For this research, the source

code was organized based on the domains the code was addressing. Essentially,

related source code was placed in a single directory and there was a separate

directory for each domain. Details of this breakdown are given in Section C.3.3.

4.8. Summary

This chapter addressed the issues involved in the selection of the

development, execution and test environment for the operational software

components being developed for this research. The process for selecting the

development and execution environment relied on independent selection of

individual sub-systems and then iteration to achieve a practical balance. Finally, a

cross-development environment was selected that relied on a SUN workstation as

the host computer on which software is developed. C++ and object-oriented

design were chosen as the programming language and the design methodology

respectively. The selection of the execution environment was primarily driven by

the computation speed of the hardware, the extensibility of the hardware, and the

availability of a real-time operating system. It was seen that a VME-based

computer with a PowerPC processor and VxWorks as the real-time operating

system was the best candidate. After the selection of the development and

execution environment it was necessary to develop the test environment. As the

VME-based execution environment was a single-user environment, changes were

made to the development environment that allowed for code to be compiled for



156

execution on the development computer (SUN workstation) itself. Using this

setup, source code development and execution could simultaneously be

undertaken by more than one user. Additionally, simulation support was added to

the execution environment. Now the user could divert the output of their control

programs to a simulation instead of a physical robot. This approach was essential

for improving the efficiency of software development. Also, various physical

robots were made available for final testing of the control programs developed by

the user. Manual controller integration software and hardware was also provided

as a part of this environment. This allowed for rapid testing of different manual

controllers and provided a means of teleoperating physical robots or simulations.

The ultimate application of this research will be to manufacturing cell

control. The distributed environment shown in Figure 4.7 will be modified to

support full cell control. However, the basic principles of object-oriented design,

distributed control, and real-time control will still apply. A preliminary layout of

the manufacturing cell control environment is shown in Figure 4.14.



157

3D Graphics

Simulation

Manual Controller

Personal Computer

Long Distance

Communications

Performance IndexPersonal Computer

KraftTeachBall

ComputationalAccelerator

PerForce

Sensor Model andFault-Detection and

Identification

Personal Computer

Local Data

Analysis

Archiving (LessonsLearned) Personal

ComputerStorage Media

User Reconfigurable

Interfaces

Personal Computer forSupervisory Control of

Manufacturing Cell

Controlled Robots andOther Machines

TOS

Figure 4.14: Future Distributed Environment for Cell Control.



158

Chapter Five

5. Abstraction Development

5.1. Introduction

The presence of a large base of component suppliers is characteristic of a

mature industry. For example, the automobile industry is supported by a large

base of ancillary industry. Also, the personal computer hardware market has a

distinct component industry. Surprisingly, the component industry is barely

present for software (a major U.S. industry). This lack of a component industry is

even more noticeable in the arena of intelligent machine software. However, the

software component industry is growing mainly due to the popularity of object-

oriented design.

Object-oriented design allows the building of software components with

standardized interfaces and reuse capability. This reuse is achieved by generality

and extensibility. Generality refers to the ability of one system to serve, without

modification, in a large range of circumstances. An example of generality is

when the same forward kinematics component can be used for different robots.

Extensibility of a system refers to the ability of a system to be modified

easily to better meet a particular need. An example of a general and extensible

system is a personal computer (PC). A PC can be used for a wide range of



159

purposes, ranging from word-processing to programming. Thus, reuse is

achieved through generality. A PC can also allow for hardware modifications

like additional memory. This is reuse through extensibility. Extensibility can be

achieved in two ways. The first, specialization, allows for the customization of an

existing component by changing, extending or even constraining based on need.

Thus, a user can extend the functionality by writing code that is combined with

the existing implementation to form a “new” implementation. This is also called

inheritance. The second means of extensibility is through containment. Using

containment, a variety of components can be grouped together to make a new

higher level component that hides the working details of the components it is

made of, thus giving it a black-box appearance. Borrowing from cognitive

science and entity-relationship information modeling, specialization and

containment are also respectively termed as IS-A and HAS-A relationships

[Coplien, 1994].

A literature review of robotic software systems showed that none of these

systems provided an architecture for generalized kinematics, dynamics, deflection

compensation, and decision making. Moreover, object-oriented design was onlyused to provide better robot programming interfaces. In addition, most of these

systems were implemented keeping in mind the scarcity of computer resources

and limited CPU power. This constraint made these systems excessively specific

and inextensible (see Chapter Two for detailed background information).

Availability of inexpensive computer power will be a key factor in the

design of future machines. Thus, it is necessary to research robotic software

systems with an awareness of the present and future state-of-the-art in computing.

Currently, advanced UNIX workstations offer 400 MFLOP performance [Lewis,

1994]. This performance level is sufficient to implement full dynamics,

kinematics, deflection modeling, and some criteria-based decision making

[Hernandez et al., 1989]. Also, the gap between personal computers and



160

workstations is decreasing. A ten time increase in the performance of personal

computers by the year 2000 is predicted. This will lead to desk-top personal

computers capable of 800 million-instructions-per-second (MIPS) [Lewis, 1994].

Currently, advanced workstations and low-end super-computers offer this

performance level. This prediction for computer technology has a definite impact

on this research. With a decrease in the price-performance ratio of computer

hardware, software will be the commodity that will be more expensive than the

hardware. To warrant this high value in the software, researchers will be forced

to develop generalized algorithms using the latest in software design and

engineering methodologies: methodologies that promote reuse and extensibility.

Thus, a software environment is needed that fully exploits the

breakthroughs in computer hardware and software technology. This environment

should provide the researcher with a system built on a framework of generalized

kinematics, dynamics, deflection modeling, criteria-based decision making, and

fault-tolerance. This system should also support a 3D graphic modeling

environment that allows for visualization, demonstration, and testing. The

software for this environment should be developed using object-orientedmethodology, thus providing a path for reuse and standardization. Moreover, this

software should be equally applicable to real-time control. The user should be

able to divert the output of this software from a graphical environment to an

actual hardware environment with minimal effort. The software environment

described above has been developed as a part of this research. This software

architecture and its development environment is also collectively called in this

report the Operational Software Components for Advanced Robotics (OSCAR).

The literature reviewed for this research clearly showed that object-

oriented design was an efficient means of developing reusable software

components for intelligent machines. These components have a black-box

appearance and abstract the functionality of the software thus allowing an



161

application developer to design software at a higher level of abstraction. This

allows for rapid-prototyping.

There are three major steps that are involved in designing object-oriented

software components. The first step is the analysis of the problem domain. This

usually leads to the breakdown of the domain into sub-domains. The net result of

the analysis phase is a set of entities and the relationships between the entities.

The functionality of these entities is also defined in this phase. The next step is

the software design. Decisions are made in the design phase based on the

execution environment, the programming language, and the operational

constraints. The entities identified in the analysis phase take the form of classes

and objects in the design phase. The third step is the implementation of the

software. These three steps are iterative and there is communication back-and-

forth among the three phases. The next section describes these three phases of

object-oriented development in detail.

5.2. Abstraction Development Process

The quality of a product is most influenced by its architecture and design.This is not a new phenomenon and has been addressed by designers through out

engineering history [Pahl and Beitz, 1988]. The architecture and design of

products is specified in the earlier stages of product development. This puts in

place the long-term sustaining structure of the product. A well designed structure

will endure well and accommodate evolution gracefully. The object-oriented

paradigm was discussed in Chapter Two. This paradigm is well-suited to

structuring a wide variety of complex systems and the key to successful

application of this paradigm is an understanding of what things make good

classes, objects, and member functions, and what things do not. The following

sections describe the three major steps that were followed for abstraction

development for this research. These are analysis, design, and implementation. It



162

should be noted that the design technique described is not formal; most

techniques in practice are not. The human mind is the best “tool” to support these

techniques. [Coplien, 1994]

5.2.1. Analysis

Mellor et al. [1988] state that “the purpose of analysis is to provide a

description of a problem. The description must be complete, consistent, readable,

and reviewable by diverse interested parties [and] testable against reality.” In

essence, the purpose of analysis is to provide a model of a system’s behavior.

Thus, an analysis should yield a description of what a system does and not how it

does it. In object-oriented terminology, this means identifying the entities that

comprise the system. Broadly, the analysis process can be broken down into the

following steps [Coplien, 1994]:

Identify the entities that comprise the application domain. Entities can often

be selected by picking the nouns from the problem statement provided by end

users. These may be resources, events, or other well-defined “crisp” areas of

specialization or expertise. For example, if the user expects a software for traffic-

light control, a traffic-light can be made an entity. The selected entities generally

map to classes or objects in the design and implementation stage. Some rules of

thumb can be used to select entities and gauge their quality:

⇒ It should be easy to identify and name the behaviors of an entity.

⇒ The entity’s behaviors should relate to each other and to the entity in an

intuitively satisfying way.

⇒ The size of the abstraction should be appropriate (see Coplien [1994] for

details).

⇒ If two implementations of an entity are not possible, a broader abstraction is

probably needed. [Coplien, 1994]



163

Identify the behaviors of the entities. This is the second step in the analysis

process for object-oriented software development and it involves identifying the

responsibilities of the entities in the application. These responsibilities are

characterized by the services and behavior of the class. “Good” behaviors are

crisp, clear, and concise. Again, the key here is to have a minimal possible

interface that provides the maximum possible functionality and is broad enough

to serve a wide variety of systems within the application domain.

Identify the relationships between various entities. Like real-world entities,

software entities also have relationships. These relationships can be mapped

directly onto corresponding C++ class and object structures. Some of the

relationships that can be possible are described below:

The IS-A Relationship. IS-A is a specialization relationship between classes.

For example, a four-by-four homogenous transformation matrix is a type of

matrix. The IS-A relationship maps to an inheritance hierarchy in the

implementation phase. Here the four-by-four homogenous transformation

matrix class will be derived from the matrix class, and thus would inherit its

functionality. [Coplien, 1994]The HAS-A Relationship. A HAS-A relationship connotes containment.

This relationship can be used to express the containment of a class within

another class, or of an object (instance of a class) between a class, or of an

object within an object. For example, in the case of a software for zoo

management, in all probability there will be a zoo and an animal entity.

Additionally, the zoo entity will have a set of animal entities inside it. For

example, “the zoo has a Zebra.” [Coplien, 1994]

The USES-A Relationship. The USES-A relationship is present if the

function interface of a class takes an instance of some other class (which it

uses) as a parameter. USES-A relationships are used when two classes need

to collaborate to accomplish the task. For example, consider a software



164

architecture for the management of an organization. Assume that there are

classes for Vice President and Department Head. In all probability the

interface for the Vice President class may have a function that takes the

Department Head as a parameter. This function may be used by the Vice

President to accomplish some joint task. In this case, the Vice President uses

the department head but does not have him. [Coplien, 1994]

Thus, in brief, the analysis phase results in the identification of key

components that make up the software systems. The relationships between the

various components and their interface is also defined. The next section describes

the second step in object-oriented program development.

5.2.2. Design

The design phase leads to the specification of classes and objects. The

entities that were defined in the analysis phase are good candidates for this. Some

of the entities map onto objects in the running program and generalization of

some entities maps onto classes. At this point names are given to classes and

these names should reflect the semantics of the application domain. [Coplien,

1994]

The design phase also involves defining relationships. As mentioned

before, the analysis phase identified the relationship between entities. In the

design phase these relationships are transformed into inheritance hierarchies or

containment relationships. [Coplien, 1994]

5.2.3. Implementation

The implementation phase of the object-oriented program development

involves filling in the details of the class data structures, adding internal

functionality to support overall class functionality, and writing member functions.



165

Additionally, unit testing of the member functions and classes, and fine-tuning of

the system should take place during implementation.

It should be noted that analysis, design and implementation are not

sequential steps. The activities are performed in a back-and-forth order,

sometimes even in parallel, until iteration comes to a minimum and the system

converges on stability. Also, under the object paradigm, the focus is more on the

design of the pieces rather than the interactions of the pieces. Interactions are, of

course, important as they are what get the job done. However, architectural

integrity of the system comes from the structure of its interfaces: object

interfaces create structures that tend to encapsulate change well and evolve

gracefully [Coplien, 1994]. This philosophy is the same as professed by

traditional mechanical designers, that is, “design in parts” [Pahl and Beitz, 1988].

5.3. Abstraction Development

Overall, the goal of this research is to perform an analysis of the domain

of advanced robotic systems and design a software architecture that allows for

extended program development for these systems. This architecture includes thespecification of software components (classes in C++). This includes their

interface, functionality, and their relationship with other components (which

might be called modules). As mentioned earlier, a requirement of these

components is to exhibit reuse through generality and extensibility. The first step

in the development of the software components was the analysis of the problem

domain of advanced robotics. This analysis is presented below:

Analysis of The Advanced Robotics Domain

Chapter One introduced some of the constructs involved in advanced

robotic systems. These were generalized kinematics, dynamics, deflection

modeling, performance criteria, and fault-tolerance. Chapter Two discussed the

mechanical and computer hardware aspects of advanced robotics and their impact



166

on the software requirements. It was concluded that to have a functional

advanced robot, operational software components had to be developed for a

manipulator in the following areas:

• geometric properties,

• compliance properties,

• dynamic properties,

• generalized inverse,

• performance criteria.

The areas outlined above provide the sub-domains of the advanced robotic

domain. An analysis had to be performed on each of these domains and key

components had to be identified. After that, software components were to be

designed, implement, and tested. However, before this was done, it was

necessary to identify other domains whose development would be necessary to

support the development of the advanced robotics sub-domains. These domains

can be divided into two categories. These are:

• domains that provide building blocks for the robotic components, and

• domains that facilitate the development and testing of the robotic components.

As far as domains that provide building blocks for robotic components are

concerned, it was observed that advanced robotics relies heavily on linear algebra

[Thomas and Tesar, 1982][Hooper, 1994]. Thus, for effectively developing

operational software components, it was necessary to develop software

abstractions that supported various linear algebra constructs. Hence, another sub-

domain of mathematical abstractions had to be established.

To facilitate development and testing of operational software components,it was necessary that some utility components be provided. For example,

software had to be provided that could be used for program timing. Besides these

domains, software components were developed that allowed for communication



167

and for interfacing with external hardware. Also, domains that provided key data

structures (example, linked-list, trees, etc.; for details on data structures, see

Horowitz et al., [1993]) had to be provided to facilitate software development.

Additionally, software components had to be developed that could act as

containers for robotics-related data. For example, a software component had to

be developed that could hold the Denavit-Hartenberg [Craig, 1986] parameters of

a serial robot arm. This component acted as a container for the geometric data of

the robot.

Table 5.1 gives a listing of the sub-domains that were developed as a part

of this research. This table also gives a brief description of the domain and the

functionality supported by the software components in that domain.



168

Domain Functionality Base • Base entity that acts as the parent of all components

• Supports functionality common to all components Mathematical • Support for linear algebra constructs

• Matrices, vectors, tensors, etc. [Strang, 1988]• Provides building blocks for operational software constructs

Robot Data • Support for storing robotics-related data and perform errorchecking on the data

• Automatic initialization from data files• Examples are Denavit-Hartenberg parameters, inertia tensors,

center-of-gravity data, etc.

Forward Kinematics • Position-level• Velocity-level• Acceleration-level• Kinematic influence coefficients [Thomas and Tesar, 1982]

Inverse Kinematics • Inverse Kinematics solution• Resolved-rate motion control [Nakamura, 1991]• Direct-search technique [Hooper, 1994]• Hybrid inverse technique (see Chapter Three)• Closed-form and generalized approaches• Level III Fault-tolerance

Performance Criteria • Abstract components for performance criteria• Example performance criteria [Hooper, 1994]• Criteria fusion (see Chapter Three)

Dynamics • Newton-Euler inverse dynamics [Craig, 1986]• Lagrangian dynamics [Thomas and Tesar, 1982]• Complete description of physical plant

Deflection Modeling • Deflection prediction in serial manipulators [Fresonke et al.,

1988]• Deflection due to joint and link compliance• Generalized spring

IODevices • Abstract input-output device classes• Serial-ports• Keyboard

Utility • String classes• Timing classes• Error handling

Communication • Inter-process communication• Network communications• Client-server classes using TCP [Brain, 1994]

Others • Key data structures

• Container components• Wrapper classes for encapsulating OS functionality

Table 5.1: A Listing of Key Domains and their Functionality.



169

Once the key sub-domains were selected, the next step was the analysis of

the sub-domains. This analysis led to the identification of the key entities in the

sub-domain. During the analysis phase, it also was decided that all the sub-

domains should be linked. This is because all these sub-domains belong to a

common domain of operational software. Thus, a basic entity called ‘Base’ was

created. All the other entities in this software architecture are of type Base. The

advantage of this was that functionality common to all entities could be provided

in the Base entity.

Design of The Advanced Robotics Domain

The design issues are not significant at the domain level. However, design

does achieve a significant role at the component level. That is, whenever an

analysis on a particular component is completed, design plays a key role in the

generation of implementation level specifications. As such, this section discusses

some of the design issues that were common to the design of all components in

this research. These issues are discussed below:

• All software classes developed as a part of this research had to have ‘RR’

prefixed to their name. This was done to avoid polluting the name space. Forexample, if in the future a new set of mathematical abstractions were made

available, the chances of these abstractions containing a matrix class with the

name ‘RRMatrix’ would be rare. However, if the matrix class developed as a

part of this research was named ‘Matrix,’ there would be a greater chance of a

name conflict. Other details of design and implementation guidelines are

provided in Appendix A.

• As the software developed in this research was to be applicable to real-time

control, computational efficiency was critical. However, object-oriented

program development in C++ relies on dynamic binding and operator

overloading (see Section 2.5.1.2 for details). Both dynamic binding and

operator overloading can slow down program execution. Thus, it was decided



170

that dynamic binding should be used only where it was necessary. The

necessity was decided by asking a simple question: “would the elimination of

dynamic binding eliminate the reuse potential of a component?” If the answer

was yes, dynamic binding was used. Otherwise, dynamic binding use was

based on how critical the component under question was to the real-time

operation of the robot.

• Operator overloading was provided to simplify program development.

However, all the functionality implemented using operator overloads was also

exposed through another more efficient interface. Thus, a user developing

programs for simulation could use the operator overloads for ease-of-use. A

real-time applications developer could use the other, more computationally

efficient, interface. An example of this is given for the RRMatrix class. The

RRMatrix class implements an operator overload for multiplying two

matrices. Another, more computationally efficient interface is also provided

for multiplying matrices. The usage of both these interfaces is shown below:

RRMatrix A(2,3); // create a 2 X 3 matrix

RRMatrix B(3,2); // create a 3 X 2 matrix

RRMatrix C(2,2); // create a 2 X 2 matrix

C = A * B; // use an overloaded function to multiply ‘A’

// and ‘B’ and to store the result in ‘C.' A

// temporary Matrix is created to return the

// results of the multiplication to ‘C’

A.Multiply(B, C); // use a computationally more efficient

// approach for multiplying ‘A’ with ‘B.’

// A temporary matrix is not created in this case

5.3.1. Base Abstraction

This sub-domain provided the base entities that would act as the parent

entities of all the other entities identified in this research. This entity is more of a

“place-holder” for future enhancements to the operational software architecture

being developed as a part of this research. Functionality added to this abstraction

is automatically inherited by the other entities that are derived from it. Currently,



171

the key attribute of this abstraction is its name. Functionality is provided to

access this name and change it. This abstraction is implemented as a C++ class

and is appropriately named ‘RRBase.’ The interface for the RRBase class is

outlined in Section B.1.1.

5.3.2. Mathematical Abstractions

The key use of mathematical abstractions was to provide building blocks

for developing the operational software components. A review of robotic

literature provided a basis for the development of mathematical abstractions

[Nakamura, 1991][Thomas and Tesar, 1982]. The following requirements were

gathered from the literature review.

• Vectors, matrices, and tensors are an efficient means of managing data in

kinematics, dynamics, and deflection modeling [Thomas and Tesar, 1986].

• Homogenous transformation matrices are extensively used to express spatial

relationships in kinematics.

• Different conventions can be used to express spatial orientations. These are,

fixed-angle representations and Euler-angle representations [Craig, 1986].• Various linear algebra constructs like matrix inversion, factorization, singular

value decomposition, vector inner and cross products, etc., are essential for

operational software development.

Considering the requirements given above, the mathematical abstraction

sub-domain was further divided into the following software components. These

are listed in Table 5.2 and brief descriptions are also given. The following sub-

sections discuss the analysis and design issues faced in the development of the

software components listed in Table 5.2.



172

5.3.2.1. Vector

A vector is a one dimensional array that is used to store data. It is a key

construct in robotics and is used to store position vectors, joint vectors, and any

other type of contiguous data. An analysis and design of the vector abstraction is

provided in the following paragraphs.

Analysis

A vector abstracts the functionality of a one dimensional array. Its

attributes and desired functionality are outlined below:

• The important attributes of a vector are the elements it contains and the size of

the array.

• The array should be range checked, that is, every time an element is accessed

a check is made to make sure that the element is within the range of the array.

• A vector should be of variable size.

Mathematical Component Description

Vector ⇒ A one-dimensional array of variable size

Position Vector ⇒ A vector for holding three numbers⇒ Can be used to express position vectors,

coordinates, or axes

Position and Orientation Vector ⇒ A vector for holding six numbers⇒ Holds the position and orientation of a vector

Matrix ⇒ A two dimensional array of variable size

Homogenous Transformation Matrix ⇒ A four-by-four matrix that can be used toexpress the position and orientation of a vector

Rotation Matrix ⇒ A three-by-three matrix that can be used toexpress the orientation of a vector

Tensor ⇒ A three dimensional array⇒ Basically an array of matrices

Table 5.2: Key Components of the Mathematical Domain.



173

• A vector should be able to contain any type of data. For example, the user

should be able to create a vector of integers, real, complex numbers, or even a

vector of matrices. This way maximum reuse can be achieved.

Design

The design of the vector abstraction involved generating implementation

level specifications from the information supplied by the analysis. These

specifications are outlined below:

• The vector abstraction was named RRVector.

• Memory allocation for an array takes place in contiguous blocks on the heap

(free store) as the size of an array, in most cases, is not known at compile

time (see Coplien [1994] for details on memory allocation).

• Functionality for accessing and setting elements of an RRVector with range

checking is provided. Additional functionality for element access without

range checking is also provided for execution speed.

• This class is implemented as a parameterized type for maximum reuse

potential (see Coplien [1994] for details on parameterized types). Thus, an

RRVector that holds integers, floating point numbers, or any other data type

(user defined type included) can be created.

Example

RRVector has a general application in robotics and can be used to express

joint position, velocity, acceleration, or any other data that needs an array

representation. The interface for the RRVector class is outlined in Section B.2.1.

An example use of RRVector is shown below:

RRVectorD JointPosition(7); // an array of doubles of size 7 with all elements = 0.0

JointPosition[0] = 10.0; // set element 0 equal to 10.0 degrees



JointPosition = JointPosition * 3.14159/180.0; // convert angles to radians

double norm = JointPosition.Norm(); // compute the norm of JointPosition



174

5.3.2.2. Position Vector

A position vector is a three dimensional vector that is used to holdcoordinate information. It can also be used to hold any three numbers. Position

vectors are extensively used in robotics to describe the relative position of

coordinate frames. The analysis and design issues faced in the development of

the position vector component are given below:

Analysis

• The attributes of a position vector are its size (that is, three) and the data it

holds.

• A position vector is a type of a vector. This signifies an IS-A relationship.

• Functionality should be provided to support individual element access, inner

product, and cross-product.

Design

• Position vector component was named RRVector3.

• Since RRVector3 is a type of RRVector, it is derived from RRVector and it

thus inherits the functionality of RRVector.

• Additional functionality is provided for valid constructs like inner product,

cross product, etc.

• Some of the functionality inherited from RRVector is redefined in the

RRVector3 class. For example, the functionality for computing the norm, and

adding and subtracting two RRVectors is redefined for computational

efficiency.

• The memory allocation of the base class (RRVector) is overridden in the

implementation of RRVector3. Efficient memory management is achieved by

RRVector3 by allocating memory on the stack . This is possible because the

size of an RRVector3 is fixed at compile time. Memory allocation on the

stack is more efficient because the stack can grow only in one direction (up or



175

down). Thus, there are no fragments of the stack that lie unused. The

allocated area of the stack is at one end and the unallocated area is at the other

end. In the simplest case, memory allocation on the heap takes place in any

spot where a contiguous block of memory that fulfills the demand is available.

This can lead to fragmentation of the heap. A fragmented heap can lead to

slower memory allocation as it can take a longer time to search for a

contiguous free memory area that satisfies the demand.

Example

RRVector3 objects are extensively used in robotics to represent position

vectors, direction cosines, etc. The interface for the RRVector3 class is outlined

in Section B.2.2. An example use of an RRVector3 is shown below:

RRVector3 X, Y, Z; // creates three RRVectors whose elements are 0.0

X[0] = 1.0; // now X = [1.0 0.0 0.0]

Y[1] = 1.0; // now Y = [0.0 1.0 0.0]

Z = X * Y; // cross X with Y. operator * is overloaded to work as cross product.

cout << “Z = X * Y = “ << Z << endl; // print the value of Z (0.0, 0.0, 1.0)

5.3.2.3. Position and Orientation Vector

Similar to position vector, position and orientation vector is a vector of

size six that is explicitly used to store the position and orientation of a vector in

space. The analysis and design issues faced in the development of the position

and orientation vector are discussed below:

Analysis

• The attributes of a position and orientation vector are the position data of the

vector and its orientation. The position is expressed by the X, Y, and Z

Cartesian coordinates. The orientation is expressed by any of the angle-sets.

These can be any of the twelve fixed-angle sets or any of the twelve Euler-

angle sets [Craig, 1986].

• Position and orientation vector is a type of vector. This implies an inheritance

relationship.



176

• Functionality should be provided that allows for conversion of a position and

orientation vector into a four-by-four homogenous transformation matrix

representation.

Design

• The position and orientation vector component is given the name

RRHandPose. This was done because, under the domain of robotics, this

component was generally used to express the position and orientation of the

hand of a robot arm.

• RRHandPose was derived from RRVector as it is a type of RRVector.

• As the size of RRHandPose is fixed (size is six), RRHandPose overrides the

memory management of its parent, the RRVector. Memory allocation for

RRHandPose takes place on the stack as opposed to the heap.

• Functionality to convert an RRHandPose to an RRXform (see Section 5.3.2.5

for details on RRXform) is also provided.

Example

RRHandPose is used in robotics to represent the position and orientation

of a vector in space. By changing the angle representation (any of the Euler or

fixed angles) of the orientation, different means of controlling the end-effector

position orientations can be exercised. The example shown below creates an

RRHandPose object and specifies that the orientation be expressed in ZYZ Euler

angles. After that, the ’X’ coordinate and the Alpha and Gamma angles are set.

The next step converts the RRHandPose object into its RRXform representation.

The interface for the RRHandPose class is outlined in Section B.2.3.

RRHandPosehand(EULER_ZYZ); // create an RRHandPose vector that

// represents the Cartesian position and the

// ZYZ Euler angles

RRXform handMatrix; // create a 4 X 4 transformation matrix

hand.X() = 10.0; // set X = 10.0

hand.Y() = 5.0; // set Y = 5.0 and Z = 0.0 by default

hand.Alpha() = 0.1; // set alpha angle = 0.1 radians

hand.Gamma() = 0.2; // set Gamma = 0.2 radians. Beta = 0.0



177

handMatrix = hand.ToTransform(); // convert hand into its 4 X 4 representation

5.3.2.4. Matrix

A matrix is a key linear algebra construct that is used to hold two-

dimensional data. The data held by a matrix could be integers, real numbers, or

complex numbers. The following paragraphs discuss the analysis and design

issues faced in the development of the matrix component. Finally, an example

use of this component is given.

Analysis

This software component abstracts the functionality of a matrix. A matrix

represents a two-dimensional array whose attributes are its elements and the

number of columns and rows.

The desired functionality of a matrix is listed below:

• Individual elements of the matrix should be accessible.

• Individual rows and columns should be accessible.

• Support linear algebra operations like inversion, transpose, LU

decomposition, singular value decomposition, etc. [Strang, 1988].

Design

The design of the matrix class involved generating specifications that

could be used for implementation. The design decisions and the reasons for

making them are listed below:

• RRMatrix was chosen as the name for the matrix abstraction. This name

effectively describes a matrix.

• Functionality was provided for inverting, transposing, singular value

decomposition, LU decomposition, multiplying, and adding matrices.

• Operator overloads were provided for multiplication, inversion, addition, and

subtraction. This was done for ease of use.



178

• As a matrix object was supposed to store integers, reals, and complex

numbers, the matrix class was designed as a parameterized class (see Coplien

[1994] for details on parameterized types). This was done to achieve

maximum reuse.

• Memory allocation for an RRMatrix takes place in contiguous blocks on the

heap (free store) (See Coplien [1994] for details on memory management) as

the size of the matrix, in most cases, is not known at compile time. As a

matrix is a two-dimensional array, different memory layouts for the elements

of a matrix are possible. Figure 5.1 shows three of these layouts. The first

one allocates a contiguous block of memory whose length is equal to the

number of rows (NROW) multiplied by the number of columns (NCOL). For

accessing an element of this matrix, a simple calculation (see Figure 5.1, part

a) has to be performed. Figure 5.1, part b shows the second memory layout.

In this, each row of size NCOL is allocated separately and a column of

pointers of size NROW is also allocated. Elements are accessed by indexing

into the column of pointers and reaching the desired row. Then the desired

element is accessed from that row. The third scheme is similar to the first in

the way it allocates memory for the elements. To avoid calculation for

accessing an element, a column of size NROW is used. This column holds

pointers to the beginning of each row in the memory layout of the elements.



179

NROWS * NCOLS

(I, J)

(I-1)*NCOL + J

*

(a)

NROW

NCOLS(I, J)

J

*

Ith Element

(b)

NROWS * NCOLS

NROW

(I, J)

NCOLS

*

J

Ith Element

(c)

Figure 5.1: Memory Allocation Schemes for a Matrix.



180

The memory layout schemes shown in Figure 5.1 have their respective

advantages and disadvantages. Two criteria can be used to analyze a

particular scheme. The first is time to allocate memory for a matrix (that is,

the time to create a matrix) and the second is time to access an element of the

matrix. The first scheme (Figure 5.1, part a) is the fastest for allocation speed

as it involves only one allocation. The second scheme (Figure 5.1, part b) is

the slowest for allocation as it involves NROW+1 allocations. The third

scheme involves two allocations. Element access speed is the same for the

second and the third scheme and is the slowest for first method. For

computations where matrices are preserved, the third scheme is the best as it

provides maximum computational efficiency and the second minimum

allocation time. This is the default scheme in the RRMatrix class. The user

can override this memory allocation scheme in a derived class. The

performance issues for the three memory allocation schemes shown in Figure

5.1 are summarized in Table 5.3 and the selected scheme is highlighted.

Example

The following example illustrates use of the RRMatrix class. First two

matrices ‘A’ and ‘B’ are created. These are of size four-by-five and five-by-four

respectively. After that, some of the elements of these matrices are set to various

values. The matrices ‘A’ and ‘B’ are then multiplied (operator ‘*’ is overloaded

for multiplication) and the result stored in ‘C.’ The next step involves inverting

Criteria Scheme a Scheme b Scheme c

Elements Access Time Slowest Fastest Fastest

Number of Allocations One NROW + 1 Two

Table 5.3: Comparison of Various Memory Allocation Schemes.



181

‘C.’ It should be noted that the operator ‘~’ is overloaded for inverting a matrix.

The interface for the RRMatrix class is outlined in Section B.2.4.

RRMatrix A(4, 5), B(5, 4); // create two matrices that contain doubles.

// By default, the matrices will be filled with zeros

A(0,0) = A(1,1) = A(3,2) = 3.0; // set some elements of A to the value 3.0

B(0,0) = B(1,2) = A(2,3) = 4.0; // set some elements of B to the value 4.0

RRMatrix C = A * B; // matrix C is created and initialized with the product

// of A and B

RRMatrix D = ~C; // matrix D is created and initialized with the inverse

// of C

5.3.2.5. Four-by-Four Homogenous Transformation Matrix

Four-by-four homogenous transformation matrices are used to represent

the relative position and orientation of two different coordinate frames. In

robotics, homogenous transformation matrices are used to represent link frames,

end-effector position and orientation, and transforms; and are used in kinematic

computations [Craig, 1986].

Analysis

The homogenous transformation matrix has the following attributes and

functionality:

• A homogenous transformation matrix is a type of matrix. This clearly

signifies an IS-A relationship. In the design phase this will map to an

inheritance relationship.

• The size of a homogenous transformation matrix is four-by-four.

• The structure of a homogenous transformation matrix consists of an upper left

three-by-three rotation matrix ( r 11 , r 12 , …, r 33 ) and the top three rows of the

last column containing the position data ( p x , p y , p z ). This is shown below:

r r r p

r r r p

r r r p

x

y

z

11 12 13

21 22 23

31 32 33

0 0 0 1



182

• The user should have the ability to convert a homogenous transformation

matrix into its vector representation. The vector representation will include

the position vector ( p x , p y , p z ) and a three-by-one representation of the

orientation. The orientation representation could be any of the fixed-angle or

Euler-angle sets [Craig, 1986].

Design

The following decisions were made for the design of the four-by-four

homogenous transformation matrix data type.

• This data type was given the name RRXform.

• As RRXform is a type of RRMatrix, RRXform is derived from RRMatrix and

thus inherits all the functionality of an RRMatrix.

• Efficient memory management is achieved by RRXform by allocating

memory on the stack. This is possible because the size of an RRXform (four-

by-four) is fixed at compile time. RRXform overrides the memory allocation

of its parent class, the RRMatrix, which allocated memory on the heap.

• RRXform redefines the functionality for matrix multiplication, inversion,

transpose, addition, and subtraction. This is done purely for reasons of

computational efficiency and could have been avoided.

• RRXform also extends the functionality of an RRMatrix by providing

functionality for conversion to a six element vector that represents the ‘X,’

‘Y,’ ‘Z’ Cartesian position and the three orientation angles (RRHandPose).

Example

The following example shows the use of the RRXform data type. First an

instance of RRXform, ‘A’ is created. ‘A’, by default is an identity matrix. The

(0,3) element of A is set to value 10.0. For doing this, a method named at is used.

The method at does not perform any range checking on its arguments. Thus, the



183

user has to exercise caution while using this method. Next the element (1,3) is set

to value -5.0. This method is an operator overload for ‘( )’ and performs range

checking on the indices and is thus safer to use. However, execution speed is

sacrificed for added safety and error checking. Once the elements of ‘A’ are set,

the next step is to convert ‘A’ into its vector representation. In the example

shown, ‘A’ is converted to an RRHandPose vector. Section B.2.7 outlines the

interface of the RRXform class.

RRXform A; // creates a 4 X 4 matrix that by default is an identity matrix

A.at(0,3) = 10.0; // this member function ‘at’ does not perform any range checking

A(1,3) = -5.0; // the ‘( )’ operator is overloaded and it performs range checking

RRHandPose handPose; // create a 6 X 1 hand position and orientation vector handPose = A.ToHandPose(); // convert A into its 6 X 1 vector representation

5.3.2.6. Three-by-Three Rotation Matrix

Three-by-three rotation matrices are used to represent the relative

orientation of two different coordinate frames [Craig, 1986]. The analysis and

design issues faced in the development of a three-by-three rotation matrix

component are discussed below:

Analysis

This rotation matrix has the following attributes and functionality:

• A rotation matrix is a type of matrix. This clearly signifies an IS-A

relationship. In the design phase this will map to an inheritance relationship.

• The size of a rotation matrix is three-by-three.

Design

The following decisions were made for the design of the three-by-three

rotation matrix data type.

• This data type was given the name RRRot3by3.

• As RRRot3by3 is a type of RRMatrix, RRRot3by3 is derived from RRMatrix

and thus inherits all the functionality of an RRMatrix.



184

• More efficient memory management is achieved by RRRot3by3 by allocating

memory on the stack. This is possible because the size of an RRRot3by3

(three-by-three) is fixed at compile time.

• RRRot3by3 redefines the functionality for matrix multiplication, inversion,

transpose, addition, and subtraction. This is done purely for reasons of

computational efficiency and could have been avoided.

Example

The following example shows the use of the RRRot3by3 data type. First

an RRRot3by3 object ‘A’ is created. Also, two RRVector3’s, ‘B,’ and ‘C’ are

created. Then some of the elements of ‘A,’ ‘B,’ and ‘C’ are set. Finally the

rotation matrix ‘A’ is multiplied with ‘B’ and the result is stored in ‘C.’ The

interface for the RRRot3by3 class in outlined in Section B.2.8.

RRRot3by3 A; // creates a 3 X 3 matrix that by default is an identity matrix

RRVector3 B, C; // create two RRVector3 objects. By default all elements are 0.0

A.at(0,1) = 10.0; // the member function ‘at’ does not perform any range checking

A(1,1) = -5.0; // the ‘( )’ operator is overloaded and by it performs range checking

B[1] = 3.0; // set the second element of B to 3.0

A.Multiply(B, C); // multiply A with B and store the result in C. That is, C = A * B

5.3.2.7. Tensor

A tensor is a three-dimensional array. It is used in robotics software to

express kinematic influence coefficients [Thomas and Tesar, 1984]. The various

analysis and design decisions made during the development of a tensor data type

are discussed below:

Analysis

• The key attributes of a tensor are the number of rows and columns of each

plane of the tensor, the total number of planes the tensor has, and the data the

tensor holds.

• The tensor should be of variable size. That is, the user should be able to

create a tensor at run time of any desired dimension.



185

• A tensor is a three dimensional matrix. In other words, a tensor is an array of

matrices, or a tensor has matrices.

• A tensor should support functionality for accessing individual elements, rows,

columns, and the matrices that comprise the tensor.

Design

• The tensor data type was given the name RRTensor.

• As a tensor is an array of matrices, an array of RRMatrix objects were

contained inside an RRTensor. Thus, RRTensor provides an example of

abstraction development through containment.

• The RRTensor provides a simplified interface for accessing the three

dimensional data inside it. Functionality is provided for accessing individual

elements and planes of the tensor.

Example

The interface for the RRTensor class is outlined in Section B.2.9 and an

example use of an RRTensor is shown below:

RRTensor A(3,4,4); // create an RRTensor of size 3 X 4 X 4. That is, a tensor

// that contains three planes of 4 X 4 matrices.

A.(0, 1,1) = 10.0; // set the (1,1) element of the plane 0 to 10.0 A.(1,2,2) = 15.0; // set the (2,2) element of the plane 1 to 15.0

A(2,3,3) = -10.0; // set the (3,3) element of the plane 2 to -10.0

A(0) = A(1) * A(2); // multiply plane 1 with plane 2 and store the result in plane 0

5.3.2.8. Summary of Mathematical Components

The previous sections discussed the analysis and design details of the

various software components that were developed as a part of the mathematical

abstractions domain. Components developed in this domain supported key linear

algebra constructs such as vector, matrices, homogenous transformation matrices,tensors, etc. The components developed in this domain were part of a class

hierarchy that is shown in Figure 5.2.



186

5.3.3. Robot Data Abstractions

The robot data domain was developed to facilitate the development and

testing of operational software. As the software components being developed for

this research had to be applicable to different robot types, it was necessary to

develop an efficient system for describing robot parameters to the softwarecomponents. This led to the development of software components that could read

data files, perform error checking on the data, and make the read data available in

a relevant format to other software components. The software components

developed as a part of this domain are listed in Table 5.4. Also listed is a brief

description of the functionality of each component.

RRBase

RRMatrix

RRXform RRRot3by3

RRTensor RRVector

RRVector3 RRHandPose

Figure 5.2: Class Hierarchy for Mathematical Domain Abstractions.



187

5.3.3.1. Robot Data

This software component is used to implement constructs that are

common to all components that read and parse data files. The analysis and design

details are given below:

Analysis

• The key attribute of this component is the name of the file that it reads data

from.

• Functionality should support opening and closing of files, counting of the total

number of tokens (valid data), and parsing through unwanted data (for

example, descriptive comments).

Design

Robot Data Component Description

Robot Data ⇒ Implements the functionality to open, close, and parsedata files

Matrix Data ⇒ Used to read data files that contain data in a matrixformat

⇒ Perform error checking on the data

Tensor Data ⇒ Used to read data files that contain data in a tensorformat

⇒ Perform error checking on the data

DH Data ⇒ Used to read data files that contain Denavit-Hartenbergparameters

⇒ Calculates the DOF of the robot and the type of joints(revolute or prismatic)

Table 5.4: Key Components of the Robot Data Domain.



188

• The Robot Data software component is implemented as an Abstract Data

Type (see Section 2.5.1.2 for details on Abstract Data Types). This is because

this component only provides the basic functionality to read files and parse

data. The actual functionality to organize the read data and make it available

is left to the derived classes.

• The class name for this data type is RRRobotData.

Section B.3.1 outlines the interface of the RRRobotData class.

5.3.3.2. Matrix Data

This software component is used to read data files that contain data in a

matrix format. The analysis and design details for this component are given

below:

Analysis


from and the data that it reads.

• Matrix Data is a type of Robot Data and it thus lends itself to inheritance in

the design phase.• Functionality should support accessing the read data element-by-element or

accessing the complete matrix.

Design

• The Matrix Data component is implemented as a C++ class and is named

RRMatrixData.

• RRMatrixData is derived from RRRobotData. The functionality to open and

close files, and to parse comments is inherited.

• Additional functionality is provided to organize the read data into a matrix

format and to perform error checking on it.

Example



189

The following example shows how an RRMatrixData class can be used to

read data files that contain data in a matrix format. Once an object of type

RRMatrixData is created, the data can be accessed from it in a manner similar to

the RRMatrix class. The interface for the RRMatrixData class is outlined in

Section B.3.2.

# This file contains an end-effector path and its name is “path.dat”# X Y Z Roll Pitch Yaw

2.0 1.1 0.2 0.3 0.4 0.12.2 1.2 0.3 0.5 0.6 0.12.1 2.2 -0.1 0.4 0.1 0.3

RRMatrixData hand(“path.dat”, 6); // open the file “path.dat” and read in the

// data in a matrix format. Each row of the // data to be read is expected to

// have six numbers

RRMatrix data = hand.GetParamaters(); // extract the read data and store

// it into an RRMatrix

5.3.3.3. Tensor Data

This software component is used to read data files that contain data in a

tensor format. That is, the data is organized as a set of matrices. The analysis and

design details for this component are given below:

Analysis


from and the data that it reads.

• Tensor Data is a type of Robot Data and it thus lends itself to inheritance in

the design phase.

• Functionality should support accessing the read data element by element or

accessing the various planes of the tensor, or accessing the complete tensor.

Design



190

• The Tensor Data component is implemented as a C++ class and is named

RRTensorData.

• RRTensorData is derived from RRRobotData. The functionality to open and


• Additional functionality is provided to organize the read data into a tensor

format and to perform error checking on it.

Example

The following example shows how an RRTensorData class can be used to

read data files that contain data in a tensor format. Once an object of type

RRTensorData is created, the data can be accessed from it in a manner similar to

the RRTensor class. In the following example, an RRTensorData object is used

to read link inertia data from a file. Section B.3.3 outlines the interface for the

RRTensor class.

# This file contains the link inertia’s of a 2 DOF robot.# The name of this file is “inertia.dat”

2.0 1.1 2.1 # Link 1 Inertia1.1 1.2 0.12.1 0.1 0.5

1.0 1.2 0.5 # Link 2 Inertia1.2 1.2 0.30.5 0.3 2.1

RRTensorData data(“inertia.dat”, 3,3); // open the file “inertia.dat” and read in the

// data in a tensor format. Each tensor is

// expected to have three rows and each

// matrix of the tensor is expected to have

// three columns

RRTensor inertias = data.GetParameters(); // extract the read data and store it

// into an RRTensor

5.3.3.4. DH Data



191

This software component is used to read data files that contain Denavit-

Hartenberg (DH) [Craig, 1986] parameter data for serial robots. The analysis and

design details for this component are given below:

Analysis


from and the DH parameters that are read from the file.

• DH Data is a type of Robot Data and it thus lends itself to inheritance in the

design phase.

• Functionality should support accessing the values of the various DH

parameters, computing the DOF of the robot whose DH parameters are read,

and also decoding the type of the joint (revolute or prismatic) from the DH

parameter data.

Design

• The DH Data component is implemented as a C++ class and is named

RRDHData.

• RRDHData is derived from RRRobotData. The functionality to open and


• Additional functionality is provided to organize the read data into a matrix

format, perform error checking, compute the DOF, and decode the type of

joint.

Example

The following example shows how an RRDHData class can be used to

read data files that contain DH parameter data. Once an object of type

RRDHData is created, the data can be accessed from it in a manner similar to anRRMatrix class. In the following example, an RRDHData object is used to read

in the DH parameters for a six DOF robot. Then the DOF of the robot and the



192

type of each joint is printed. The interface for the RRDHData class is outlined in

Section B.3.4.

# This file contains the DH parameters of the six DOF puma robot. The# variable is specified by typing a "var’ or a "VAR" in its field. That is, if the joint is revolute# then it will be in the fourth column and if the joint is prismatic it will be in the third column.# Alpha(i-1) a(i-1) d(i) theta(i)

0 0 0 var # link 0-1-90 0 0 var # link 1-20 650 190.13 var # link 2-3-90 0.0 600 var # link 3-490 0.0 0.0 var # link 4-5-90 0.0 0.0 var # link 5-6

RRDHData pumaDH(“puma.dh”); // open the file “puma.dh” and read in the data in

// the DH parameters of the puma robot int DOF = pumaDH.GetDOF(); // get the DOF of the robot

// described in “puma.dh”

cout << “Degrees-of-freedom = “ << DOF << endl; // print out the DOF

for(int I=0; I < DOF; I++){ // print out the type of each joint of the robot

cout << “Joint “ << I << “ Type = “ << pumaDH.GetJointType() << endl;

}

5.3.3.5. Summary of Robot Data Abstractions


software components developed as a part of the robot data domain. Components

developed in this domain supported reading of numerical data that was expressed

in a matrix or tensor format. The software class hierarchy for this domain is

illustrated in Figure 5.3.



193

5.3.4. Forward Kinematics

Forward kinematics is a key construct in robotics and it provides a

mapping from robot joint-space to Cartesian world-space. The forward

kinematics solution is generally computed at the position, velocity, and

acceleration-level [Craig, 1986]. Constructs from forward kinematics are used in

robot inverse dynamics calculations, inverse kinematics, deflection modeling and

criteria-based optimization [Thomas and Tesar, 1982][Nakamura, 1991][Hooper,

1994]. The following paragraph provides an analysis of the domain of forwardkinematics. Considering this analysis, key abstractions are identified and then

their detailed analysis and design follows.

Analysis

• The forward kinematics solution should be completely generalized. That is,

the same software components should apply to all possible geometries of

serial robots.

• As mentioned earlier, the forward kinematics solution is computed at the

position, velocity, and acceleration-level.

• The position-level solution is used to compute the end-effector position and

orientation for a given joint configuration. The forward position solution is

used by Hooper [1994] in the formulation of the direct-search inverse

RRBase

RRMatrixData RRTensorData RRVectorData

Figure 5.3: Class Hierarchy for the Robot Data Domain.



194

kinematics scheme (see Chapter Three and Hooper [1994] for details).

Additionally, the Newton-Euler inverse dynamics formulation [Craig, 1986] is

based on the forward position solution.

• The forward kinematics solution at the velocity-level involves computing a

mapping between the joint velocities and the end-effector velocity. This

mapping is represented as the Jacobian matrix [Nakamura, 1991]. The

Jacobian matrix can be used for computing the inverse kinematics solution

using a technique called resolved rate motion control (see Chapter Three for

details).

• Further, kinematic influence coefficients as developed by Thomas and Tesar

[1982] are based on the forward kinematics solution at the velocity and

acceleration-level. These kinematic influence coefficients can be used in the

computation of the inverse dynamics solution [Thomas and Tesar, 1982], and

robot link deflections due to loads [Fresonke et al., 1988].

• It should be noted that even though the forward kinematics solution at the

position, velocity, and acceleration are separate sub-domains, the algorithms

that they are based on make them extensions of each other [Nakamura, 1991].

This is because, the forward acceleration solution is based on the forward

velocity solution, and the forward velocity solution is based on the forward

position solution.

Based on the analysis presented above, it was concluded that five key

components had to be developed to support functionality for computing the

forward kinematics solution. These components were identified as the forward

position solution, forward velocity solution, forward acceleration solution,

Jacobian level, and partial Jacobian. The Jacobian level component is a separate

component that only computes the Jacobian matrix. Even though, the

computation of the Jacobian matrix is also supported by the forward velocity



195

solution, it was desired to have a simpler and smaller component for just

computing the Jacobian matrix. This is because the resolved rate motion control

technique relies exclusively on the Jacobian matrix. The partial Jacobian

component was created to facilitate the computation of the inverse kinematics

solution of a six DOF sub-structure of a redundant arm (see Chapter Three for

details on the algorithm). Table 5.5 lists the key components of the forward

kinematics domain.



196

5.3.4.1. Position Level

This component encapsulates the forward kinematics solution at the

position-level for any serial robot. The (DH) parameters are used as inputs for

Forward Kinematics

Component

Description

Forward Position ⇒ Computes the hand position and orientationbased on an input joint configuration

⇒ Computes all local and global transformationmatrices

⇒ Allows adjustments for the tool-point and thelocation of the robot base frame with-respect-to the world frame

⇒ Takes the DH parameters as input

Jacobian Level ⇒ Computes the Jacobian matrix for the end-effector of a robot based on an input joint

configuration⇒ Jacobian level solution is an extension of the

position-level solution

Partial Jacobian ⇒ Computes the Jacobian matrix for a six DOFsub-structure of a redundant arm

⇒ Allows the ability to select the six joints thatconstitute the six DOF sub-structure

⇒ Partial Jacobian is an extension of theJacobian level solution

Forward Velocity ⇒ Computes the complete velocity-levelsolution based on input joint configuration

⇒ This includes the rotational and translationalfirst-order influence coefficients (see Thomas

and Tesar, [1982] for details)⇒ Forward velocity is an extension of theJacobian level solution

Forward Acceleration ⇒ Computes the complete acceleration-levelsolution based on input joint configuration

⇒ This includes the rotational and translationalsecond-order influence coefficients (seeThomas and Tesar [1982] for details)

⇒ Forward acceleration is an extension of theforward velocity-level solution

Table 5.5: Key Components of the Forward Kinematics Domain.



197

creating this component. The interface of this component allows for the

computation of all local transformation matrices, global transformation matrices,

setting up the tool point, and specifying the location of the robot base frame with

respect to the world frame (an essential construct for calibration in manufacturing

cells). The reader should refer to Craig [1986] for details on the forward

kinematics solution at the position-level. The analysis and design details for this

component are presented below:

Analysis

• The key attributes of the forward position solution are the DH parameters that

represent the robot geometry, an array of local transformation matrices, an

array of global transformation matrices, the location of the tool point, and the

location of the robot base frame with respect to the world frame.

• The functionality should support the computation of local transformation

matrices. The local transformation matrices can be computed from the DH

parameters by using the formulation shown below (for details see Craig

[1986]):

T

a

a

d i i

i i i i i i i

i i i i i i i

i i i( ),

cos( ) cos( ) sin( ) sin( ) sin( ) cos( )sin( ) cos( ) cos( ) sin( ) cos( ) sin( )

sin( ) cos( )− =

−−

1 0

0 0 0 1

θ α θ α θ θ

θ α θ α θ θ

α α

• The global transformation matrices are computed by multiplying the local

transformation matrix. For example, the global transformation matrix for the

nth link can be calculated as:

T T T T T T on n n= −01 12 23 34 1... ( )

• The tool point adjustments are made to the local transformation matrix of the

last link.



198

• The robot location adjustments are made to the local transformation matrix of

the first link.

Design

• The forward position component was given the name RRFKPosition.

• The RRFKPosition class is an example of containment. It contains an array of

RRXform to hold the local transformation matrices, another array of

RRXform to hold the global transformation matrices, an RRDHData object

for reading and holding the DH parameters, two RRVector3 objects for

holding the robot location and the tool-point.

Example

The following paragraph shows C++ code that illustrates the use of the

RRFKPosition class. First, an RRFKPosition object is created for a PUMA robot

whose DH parameters are described in the “puma.dh” data files. Then the

location of the tool point is set and the hand position and orientation computed

based on input joint angles. After that, the local transformation matrices for each

link are printed. Section B.4.1 outlines the interface of RRFKPosition.

RRFKPosition puma_fowkin(“puma.dh”); // create a forward kinematics // object for the puma robot

RRVector joints(puma_fowkin.GetDOF()); // create a vector for holding joint positions

RRXform hand; // create a 4X4 matrix for holding hand pose

joints[0] = 10.0; joints[1] = 30.0; joints[5] = -20.0; // set the robot joint position

joints *= DEGTORAD; // convert angles to radians

hand = *puma_fowkin.GetHandPose(joints); // get hand position and orientation

for(int I = 0; I < puma_fowkin.GetDOF(); I++){ // print all local transformations

cout << *puma_fowkin.GetLocalTransformation(I) << endl;

}

5.3.4.2. Jacobian Level

The Jacobian matrix describes a relationship between the joint velocitiesand the end-effector velocities. The functionality to compute the Jacobian is

provided in the velocity-level component. However, a separate Jacobian level

component was desired because of its importance in the computation of



199

generalized inverses and various performance criteria. This component “fine-

tunes” the computation of the Jacobian matrix and provides a simpler and cleaner

interface. The various analysis and design decisions faced in the development of

the Jacobian level component are given below:

Analysis

• The attributes of the Jacobian level component are the forward position

solution and the Jacobian matrix.

• This component should provide the functionality to compute the Jacobian

matrix based on an input joint angle configuration.

• As the attributes of a Jacobian level solution include the position solution, it

may lead us to believe that the position-level component (RRFKPosition)

should be contained inside the Jacobian level component. However, it was

decided to design the Jacobian level component as an extension of the

Position-level component. Using this approach, the Jacobian level component

just adds to the functionality of the position-level component.

• The elements of the Jacobian matrix can be computed from the global

transformation matrices using the formulation shown in Section 3.4.1.

Design

• The Jacobian level component was implemented as a C++ class and given the

name RRFKJacobian.

• As the Jacobian level solution is an extension of the position-level solution,

RRFKJacobian was derived from RRFKPosition.

• Functionality was defined to compute the individual columns of the Jacobian

matrix.• Additional functionality was added to compute the complete Jacobian and its

transpose.

Example



200

The following example shows the use of the RRFKJacobian class. An

RRFKJacobian object is created for the robot whose DH parameters are described

in the “rr7.dh” data file. Using this object, the Jacobian matrix is computed for a

particular joint configuration. A pseudo-inverse of the Jacobian matrix is used to

compute the joint velocities based on some given hand velocities. Section B.4.2

outlines the interface of the RRFKJacobian class.

RRFKJacobian fkJacobian(“rr7.dh”); // create an RRFKJacobian object for the

// robot described by the DH parameters

// in the file” rr7.dh”

RRVector3 toolPoint; // create a vector to store the tool point of the robot

int DOF = fkJacbian.GetDOF(); // get the DOF of the robot in question

RRMatrix jacobian(6, DOF); // create a matrix that will hold the jacobian RRMatrix jacobianTrans(DOF, 6); // create a matrix for holding the jacobian transpose

RRVector jointPos(DOF); // create a vector for holding joint positions

RRVector jointVel(DOF); // create a vector for holding joint velocities

RRHandPose handVel(FIXED_XYZ); // create a vector for holding hand velocity

jointPos[0] = jointPos[1] = 10.0; // set joint 1 and 2 to 10 degrees

jointPos[4]= jointPos[6] = -4.0; // set joint 5 and 7 to -4.0 degrees

jointPos *= DEGTORAD; // convert joint angles from degrees to radians

handVel[0] = 1.0; // set hand X velocity = 1.0

handVel[1] = -3.0; // set hand Y velocity = -3.0

handVel[4] = 0.02; // set hand Roll angular velocity = 0.02

toolPoint.Z() = 10.0; // tool point is 10 units in the Z direction

fkJacobian.SetToolPoint(toolPoint); // convey the tool point information to fkJacobian jacobian = *fkJacobian.GetJacobian(jointPos); // compute jacobian based on joint position

jacobianTrans = *fkJacobian.GetJacobianTranspose(); // get jacobian transpose

if(DOF == 6){ // multiply hand velocity with the Jacobian inverse

jointVel = ~jacobian * handVel; // ~ is an operator overload for matrix inversion

}else if(DOF > 6){ // multiply hand velocity with the pseudo-inverse

jointVel =( jacobianTrans * (~(jacobian * jacobianTrans))) * handVel;

}

5.3.4.3. Partial Jacobian Level

This software component was developed to assist in the formulation of the

generalized hybrid inverse kinematics scheme described in Chapter Three. This

scheme uses a six DOF sub-structure to solve for the inverse position kinematics



201

solution. The scheme used for solving the sub-structure inverse used resolved

rate motion control, which further relied on the Jacobian matrix. Thus, a software

component was needed that could compute the Jacobian matrix for a six DOF

sub-structure. The following paragraphs give the analysis and design details of

this software component.

Analysis

• The attributes of the partial Jacobian level component are the forward position

solution and the partial Jacobian matrix.

• This component should provide the functionality to compute the Jacobian

matrix for a six DOF sub-structure based on an input joint angle

configuration.

• Functionality should be provided to select any six joints for the partial

Jacobian. Support should also be provided to set the joint values of the

remaining joints (that is, lock the remaining joints). In essence, every time a

joint is locked to a different value, a new robot geometry is achieved. Thus,

for a ten DOF robot arm, four joints can be locked to arbitrary positions thus

achieving a six DOF robot.

• The Jacobian level component (RRFKJacobian) already provides the

functionality to compute individual columns of the Jacobian matrix. This

functionality is extended by the partial Jacobian component. This leads to an

inheritance relationship between the partial Jacobian component and the

Jacobian level component.

Design

• The partial Jacobian level was given the name RRFKPartialJacobian.

• As the partial Jacobian level solution is an extension of the Jacobian level

solution, RRFKPartialJacobian was derived from RRFKJacobian.



202

• Additional functionality was added to select the joints to include in the

computation of the Jacobian matrix, and to set the values of the remaining

joints.

Example

The following example shows the use of the RRFKPartialJacobian class.

An RRFKPartialJacobian object is created for a seven DOF robot whose DH

parameters are described in the “rr7.dh” parameter file. As this robot has one

redundant joint, only one joint can be set at a fixed value and the remaining joints

used to compute the partial Jacobian matrix. It should be noted that the partial

Jacobian is always six-by-six. Section B.4.3 outlines the interface to the

RRFKPartialJacobian class.

RRFKPartialJacobian fkJacobian(“rr7.dh”); // create an RRFKPartialJacobian

// object for the robot described by the DH

// parameters in the file “rr7.dh”

RRMatrix partialJacobian(6, 6); // create a matrix that will hold the partial Jacobian

RRVector lockedJoints(1); // create vectors for holding the locked joint

// number. The size of this vector is one, as only one

// joint can be locked

RRVector lockedJointValue(1); // create vectors for holding the value at which the

// locked joint is locked

jointPos[0] = jointPos[1] = 10.0; // set joint 1 and 2 to 10 degrees jointPos[4]= jointPos[6] = -4.0; // set joint 5 and 7 to -4.0 degrees

jointPos *= DEGTORAD; // convert joint angles from degrees to radians

lockedJoints[0] = 2; // set joint 3 of the robot as the locked joint. This

// joint will be excluded from the

// Jacobian calculation

lockedJointValue[0] = 30.0 * DEGTORAD; // set the value of the locked joint to 30 deg.

jacobian = fkJacobian.GetPartialJacobian(jointPos); // compute the partial Jacobian

// based on input joint position

5.3.4.4. Forward Velocity Solution

The purpose of this component is to provide velocity-level kinematicsolutions for serial robotic arms. This involves computing the first-order

kinematic influence coefficients (see Thomas and Tesar [1982] for more details



203

on kinematic influence coefficients). The analysis and design details for this

component are given below:

Analysis

• The attributes of this component are the forward position solution and the

rotational and translation first-order influence coefficients.

• The functionality provided by this component includes the computation of the

first-order translational and rotational influence coefficients.

• The computation of the kinematic influence coefficients uses the local and

global transformation matrices that were computed as a result of the forward

position solution. This would imply that this component should contain the

position-level component (RRFKPosition). However, it was decided to

develop the velocity-level component as an extension of the Jacobian level

component, which further is an extension of the position-level component.

This was done to gain access to the functionality of the position and Jacobian

level component and to expose the functionality of those components through

the interface of this component.

Design

• This component was implemented as a C++ class and given the name

RRFKVelocity.

• As this component is an extension of the Jacobian level solution,

RRFKVelocity is derived from RRFKJacobian. This class thus also supports

the functionality offered by RRFKJacobian and RRFKPosition.

• Functionality is provided for computing the first-order rotational influence

coefficients and first-order translational influence coefficients [Thomas andTesar, 1982]. The first-order influence coefficients can be computed for each

link of the robot and the translational influence coefficients can be computed



204

for any point on a robot link. The first-order influence coefficients are stored

in an RRTensor.

Example

The following example shows the use of the RRFKVelocity class to

compute the first-order rotational and translational kinematic influence

coefficients. First an RRFKVelocity object is created by supplying the DH

parameters of a robot. Then the kinematic influence coefficients are computed.

Section B.4.4 outlines the interface of this class.

RRFKVelocity fkVelocity(“rr7.dh”); // create an RRFKVelocity object for the

// robot whose DH parameters are

// described in the “rr7.dh” data file

RRMatrixData linkCG(“rr7.cgm”,3); // read in the location of the center of

// gravity of each link of the robot

int DOF = fkVelocity.GetDOF(); // get the DOF of the robot

RRVector joints(DOF); // create a vector to hold joint positions

joints[0] = joints[1] = joints[4] = 10.0;// set some joint angles to 10 degrees

joints *= DEGTORAD; // convert degrees to radians

// compute the rotational G functions

RRTensor* rg = fkVelocity.GetRotationalGfunctions(joints);

for(int I = 0; I < DOF; I++){ // for all the joints

cout << rg[I] << endl; // print out the rotational G functions

}

fkVelocity.SetLinkPoints(linkCG.GetParameters()); // set the location of the points on the

// links for which the translational // G functions have to be computed

// compute the translational G functions

RRTensor* tg = fkVelocity.GetTranslationalGfunctions(joints);

for( I = 0; I < DOF; I++){ // for all the joints

cout << tg[I] << endl; // print out the translational G functions

}

5.3.4.5. Forward Acceleration Solution

The purpose of this component is to provide acceleration-level kinematic

solutions for serial robotic arms. This involves computing the second-order

kinematic influence coefficients (see Thomas and Tesar [1982] for more details



205

on kinematic influence coefficients). The analysis and design details for this

component are given below:

Analysis

• The attributes of this component are the forward velocity solution and the

rotational and translation second-order influence coefficients.

• The functionality provided by this component includes the computation of the

second-order translational and rotational influence coefficients.

• The computation of the kinematic influence coefficients uses the first-order

influence coefficients that were computed as a result of the forward velocity

solution. This would imply that this component should contain the velocity-

level component (RRFKVelocity). However, the acceleration-level

component is developed as an extension to the velocity-level component.

This was done to gain access to the functionality of the velocity-level

component and to expose the functionality of the velocity-level component.

Design

• The acceleration-level component was implemented as a C++ class and given

the name RRFKAcceleration.

• As this component is an extension of the velocity-level component,

RRFKAcceleration is derived from RRFKVelocity. Thus, this class supports

the functionality offered by RRFKVelocity.

• Functionality is provided for computing the second-order rotational influence

coefficients and second-order translational influence coefficients [Thomas and

Tesar, 1982].

ExampleThe following example shows the use of the RRFKAcceleration class to

compute the second-order rotational and translational kinematic influence

coefficients. First an RRFKAcceleration object is created by supplying the DH



206

parameters of a robot. Then the kinematic influence coefficients are computed.

Section B.4.5 outlines the interface of RRFKAcceleration.

RRFKAcceleration fkAcc(“rr7.dh”); // create an RRFKAcceleration object for the robot

// whose DH parameters are described in the

// “rr7.dh” data file

RRMatrixData linkCG(“rr7.cgm”,3); // read in the location of the center of

// gravity of each link of the robot

int DOF = fkAcceleration.GetDOF(); // get the DOF of the robot

RRVector joints(DOF); // create a vector to hold joint positions

joints[0] = joints[1] = joints[4] = 10.0;// set some joint angles to 10 degrees

joints *= DEGTORAD; // convert degrees to radians

fkAcc.SetLinkPoints(linkCG.GetParameters()); // set the location of the points on the links

// for which the translational G and H

// functions have to be computed

// compute the translational G functions. // This method should be called before a call

// to GetTranslationalHfunctions

RRTensor* tg = fkAcc.GetTranslationalGfunctions(joints);

RRTensor* rh = fkAcc.GetRotationalHfunctions(2); // compute the rotational H

// function for the third joint.

cout << *rh << endl; // print out the rotational H function

RRTensor** th = fkAcc.GetTranslationalHfunctions(); // compute and get the

// translational H functions

for(int I = 0; I < DOF; I++){ // for all the joints

cout << *th[I] << endl; // print out the translational H functions

}

5.3.4.6. Summary of Forward Kinematics Abstractions


software components developed as a part of the forward kinematics domain.

Components developed in this domain supported forward kinematics at the

position, velocity, and acceleration-level. The components developed in this

domain were part of a class hierarchy that is shown in Figure 5.4.



207

RRBase

RRFKPosition

RRFKVelocity

RRFKAcceleration

RRFKJacobian

RRFKPartiaJacobian

Figure 5.4: Class Hierarchy for the Forward Kinematics Domain.

5.3.5. Inverse Kinematics

Inverse kinematics for serial robots provides a mapping from the world-

space (usually Cartesian) to the joint-space of the robot. Generally, inverse

kinematics is performed at the position-level, in which a joint angle solution or

solutions are computed based on a given orientation and position of the end-

effector [Craig, 1986]. The Inverse Kinematics class hierarchy encapsulates

position and velocity-level inverses for six DOF and redundant robot arms. Table

5.6 lists and gives a brief description of the key software components developed

as a part of the inverse kinematics domain.



208

Inverse Kinematics Component Description

Inverse Position ⇒ Abstract component that defines the interfacefor position-level inverse kinematics

Inverse Velocity ⇒ Abstract component that defines the interfacefor velocity-level inverse kinematics

⇒ This is an extension of Inverse Position

Jacobian Level Inverse ⇒ Abstract component that defines some of thefunctionality for computing the inverseposition and velocity-level solution usingresolved rate motion control

⇒ This is an extension of Inverse Velocity

Jacobian Level Inverse for Six

Degrees-of-Freedom

⇒ Computes inverse kinematics solution at theposition and velocity-level for six DOF robot

arms using the resolved rate motion control⇒ This is an extension of Jacobian level inverse

Jacobian Level Inverse for Greater

than Six Degrees-of-Freedom

⇒ Computes inverse kinematics solution at theposition and velocity-level for redundant robotarms using the resolved rate motion control

⇒ This is an extension of the Jacobian levelinverse

Jacobian Level Partial Inverse ⇒ Computes the inverse kinematics solution atthe position and velocity-level for redundantarms by using a six DOF sub-structure tosatisfy the end-effector constraints

⇒ This is an extension of the Jacobian levelinverse

Generate Options ⇒ Used to generate null-space options forredundant arms

⇒ Uses the hybrid scheme described in ChapterThree

Fault Tolerant Generate Options ⇒ Extension to Generate Options⇒ Supports Level III fault-tolerance

Hybrid Inverse ⇒ Performance criteria-based generalized inverse⇒ Utilizes performance criteria components⇒ This is an extension of inverse position⇒ This contains a Generate Options component

Fault Tolerant Hybrid Inverse ⇒ This is an extension of the Hybrid Inverse⇒ Adds Level III fault-tolerance support

Table 5.6: Key Components of the Inverse Kinematics Domain.



209

5.3.5.1. Position Level

The inverse position solution for robots involves computing the jointpositions based on an input end-effector position and orientation. RRIKPosition

merely implements the interface without specifying any functionality (hence an

abstract data type). The functionality is defined in the derived classes. The

interface for this class provides functions that compute the inverse position

solution based on a given hand transformation matrix (RRXform) or a six element

vector that specifies the position and orientation of the hand (RRHandPose).

Additional functionality is provided for setting the tool point coordinates, and the

robot base frame location with respect to the world frame. Section B.5.1 outlines

the interface of the RRIKPosition class.

5.3.5.2. Velocity Level

The inverse kinematics solution at the velocity-level involves computing

the joint velocities based on input end-effector velocities. This component is

implemented as an abstract data type and is named RRIKVelocity. Additionally,

RRIKVelocity is derived from RRIKPosition and it extends its interface toinclude functions for computing the joint velocities based on input hand

velocities. As RRIKVelocity is also an abstract data type, the functionality is

provided by derived classes. Section B.5.2 outlines the interface to the

RRIKVelocity class.

5.3.5.3. Jacobian Level Inverse

The purpose of this component is to provide functionality for computing

the generalized inverse using the resolved rate motion control technique

[Whitney, 1969]. The analysis and design details of this component are given

below:

Analysis



210

• The key input to this component is the hand position and orientation of the

end-effector. The desired output is the joint position that satisfies the input

hand positions. Additionally, as resolved rate motion control is based on a

velocity-level formulation, another input to this component is the hand

velocity. The desired output for this is the joint velocities.

• The resolved rate motion control technique is based on using the Jacobian

matrix to compute the joint velocities based on a given input hand velocity.

This is expressed as:

x J q. .

=where x

.

is a vector of hand velocities, J is the Jacobian matrix, and q.

is a

vector of joint velocities. By inverting the Jacobian matrix, the joint

velocities can be expressed in terms of the hand velocities. This is expressed

as:

q J x.

1.

= −

Further on, this can be expressed as a differential relationship between the

joint displacements and the end-effector displacements. This is expressed as:

dq J dx1= −

where, dq is the differential joint vector, J is the Jacobian matrix, and dx is

the differential hand vector. The relationship shown above can be iterated

over until the error between the desired hand position and the actual hand

position is within acceptable error bounds. Note that the computation of the

Jacobian inverse depends upon its size and the optimizations and robustness

desired. For example, for a six DOF robot, the Jacobian matrix is six-by-six

and a simple inverse based on Gaussian elimination may be sufficient.

However, if a redundant arm is in consideration, a pseudo-inverse may be

needed or a singularity robust inverse may be desired. The reader should refer



211

to Nakamura [1991] for details on different formulations for inverting the

Jacobian matrix and computing the differential joint vector based on the input

differential hand vector.

Design

The analysis provided above outlined the steps in the computation of the

inverse kinematics solution. Based on these steps, the following design

specifications were generated:

• This component is named RRIKJacobian.

• The analysis showed the reliance of the inverse solution on the Jacobian

matrix. Hence, this component had to support functionality for computing the

Jacobian matrix. This functionality was supported using containment. That

is, an RRFKJacobian object was contained within this component. The

RRFKJacobian component was used to supply the Jacobian matrix. Further,

the user has the option to supply a custom RRFKJacobian object to

RRIKJacobian or use the default RRFKJacobian object that is contained

inside the RRIKJacobian. The advantage of this is that the user can supply

the RRIKJacobian with an object that is derived from RRFKJacobian. The

user derived RRFKJacobian object may implement a more efficient method of

computing the Jacobian matrix thereby improving the computational

efficiency of RRIKJacobian.

• As this inverse solution relies on iteration, functionality was designed to allow

setting an upper bound on the iterations. Further, functionality was supplied

to detect singularities.

• Functionality was also added in three other areas. These were, functionality

to compute the error, functionality to perform the iterations until the solution

converged, and functionality to compute the differential joint vector based on

an error hand vector.



212

• As mentioned in the analysis, the technique used to compute the differential

joint vector can vary based on the DOF of the robot, and the type of the

desired solution (minimum-norm, singularity robust, joint limit avoidance,

etc.). Hence, the functionality for computing the differential joint vector was

not defined in this class. It was left to the derived classes to supply this

functionality.

Section B.5.3 outlines the interface of the RRIKJacobian class.

5.3.5.4. Jacobian Level Inverse For Six Degrees-of-Freedom

This component provides the functionality to compute the inverse

kinematics solution for six DOF robots using the resolved rate motion control

technique [Whitney, 1969]. The key analysis and design issues for this

component are:

Analysis

• This component is a specialization of the Jacobian level inverse component.

• The key functionality of this component is to compute the differential joint

vector based on an error hand vector. For a six DOF robot, this can be doneusing the following formulation:

dq J dx1= −

• The functionality for iteration and computing the error solution is defined in

the base (RRIKJacobian) class.

Design

• This component was given the name RRIKJForSix and it is derived from

RRIKJacobian.



213

• The method for computing the differential joint vector is defined in this class.

The functionality for iteration and error calculation is inherited from

RRIKJacobian.

Example

The following example shows the use of the RRIKJForSix class to

compute the inverse position solution for a six DOF robot arm. First an instance

of the RRIKJForSix class is created by supplying the DH parameters of the robot

under consideration. Also supplied are the starting initial joint angles and the

maximum desired error. Additionally, an RRFKPosition object is created to

evaluate the starting hand position based on the initial joint configuration. This

starting hand position provides a base point for the inverse kinematics. After that,

the RRIKJForSix object is used to compute the inverse position solution for

tracking a straight line path in the positive ‘X’ direction. Section B.5.4 outlines

the interface of the RRIKJforSix class.

RRFKPosition fowkin(“puma.dh”); // create a forward position object for

// the robot whose DH parameters are

// described in “puma.dh”

RRVector3 toolPoint; // create a vector to hold the tool point

RRVector initialJoints(fowkin.GetDOF())); // create a vector for holding initial // joint configuration

RRVector jointSolution(fowkin.GetDOF())); // create a vector for holding the solution of

// the inverse kinematics

toolPoint[2] = 13.0; // set the tool point to be 13 units in the ‘Z’

// direction of the local link frame of the

// last joint.

initialJoints[0] = 30.0; // set initial value of joint 1 to 30 degrees

initialJoints[2] = -60.0; ; // set initial value of joint 3 to -60 degrees

initialJoints[4] = 45.0; ; // set initial value of joint 5 to 45 degrees

RRXform hand; // create a 4X4 matrix to hold the end-

// effector position and orientation

initialJoints *= DEGTORAD; // convert angles from degrees to radians

fowkin.SetToolPoint(toolPoint); // inform fowkin of the tool point locationhand = *fowkin.GetHandPose(initialJoints); // compute the starting hand location

RRIKJForSixinvkin(“puma.dh”, initialJoints, 0.01); // create an inverse

// kinematics object for the robot whose DH

// parameters are given in “puma.dh.” The

// initial joint configuration and the



214

// maximum error limit is also supplied

invkin.SetToolPoint(toolPoint); // inform invkin of the tool point location

for(int I = 0; I < 30; I++){ // increment the ’X’ coordinate of the

hand.at(0,3) += 0.1; // current hand location by 0.1 30 times

if(invkin.GetJointPosition(hand, jointSolution) > 0){ // and compute the inverse position

cout << jointSolution * RADTODEG << endl; // solution and print it

}else{ // if no solution

cout << “singularity” << endl; // print “singularity”

}

}

5.3.5.5. Jacobian Level Inverse For Greater than Six Degrees-of-Freedom


kinematics solution for redundant robots using the resolved rate motion control

technique [Nakamura, 1991]. The key analysis and design issues for this

component are:

Analysis



vector based on an error hand vector. For a redundant robot, the differential

joint vector is computed as shown:

dq = J (J J ) dxt t 1−

,

This is also known as solving a linear system of equations using the pseudo

inverse. This formulation provides the minimum norm solution [Nakamura,

1991].

Design

• This component was given the name RRIKJForGTSix and it is derived from

RRIKJacobian.

• The method for computing the differential joint vector is defined in this class.

The other functionality for iteration and error calculation is inherited from

RRIKJacobian

Example



215

The following example shows the use of the RRIKJForGTSix class to

compute the inverse position and velocity solution for a ten DOF robot arm. First

an instance of the RRIKJForGTSix class is created by supplying the DH

parameters of the robot under consideration. Also supplied are the starting initial

joint angles and the maximum desired error. The inverse object is then used to

compute the inverse position and velocity solution. Section B.5.5 outlines the

interface to the RRIKJForGTSix class.

RRVector initialJoints(10); // create a vector for holding initial

// joint configuration

RRVector jointSolution(10); // create a vector for holding the inverse

// position solution RRHandPosejointVel(10); // create a vector for holding the inverse

// velocity solution



RRHandPosehandVel; // create a vector for hand velocity

RRIKJForGTSix invkin(“10dof.dh”, initialJoints); // create an inverse kinematics

// object for the robot whose DH

// parameters are given in “10dof.dh.”

hand(0,3) = 10.0; // current hand ‘X’ coordinate location = 10.0

handVel[1] = 2.0; // current hand velocity in ‘Y’ direction = 2.0

invkin.GetJointPosition(hand, jointSolution); // compute the inverse position solution

jointVel = *invkin.GetJointVelocity(handVel); // compute the joint velocity

5.3.5.6. Jacobian Level Partial Inverse


kinematics solution for a redundant robot arm by restricting it to a six DOF robot.

Thus, if a robot has n joints (n > 6), then n-6 joints can be locked at any desired

position. Changing the locked value of a joint or changing a locked joint to

another joint results in a new robot geometry. Functionality is provided that

allows for selection of the six joints that are to be used for the inverse solution.

These joints are henceforth called pseudo active joints. The joints other than the

active joints can be set to any desired values. These joints are referred to as the

locked joints. The inverse solution for this component is based on the resolved



216

rate motion control technique [Whitney, 1969]. The key analysis and design

issues for this component are:

Analysis



vector based on an error hand vector. As this component always restricts a

redundant robot to six DOF, the differential joint vector can be computed

using the following formulation:

dq = J dx-1

• The functionality to compute a partial Jacobian based on the six active joints

is supplied by the RRFKPartialJacobian object. This object is contained

within this component.

• The functionality for iterating until error bounds are satisfied is redefined to

take into account the locking of joints.

• Functionality is added to support the locking of joints.

• The functionality for computing the error solution is defined in the

RRIKJacobian class.

Design

• This component was given the name RRIKJPartial and it is derived from

RRIKJacobian.

• The methods for computing the differential joint vector and iterating until the

error bounds are satisfied are redefined in this class. The functionality for

error calculation is inherited from RRIKJacobian.

• Additional functionality for specifying the joints to be locked, the values at

which to lock the joints, and getting the status of a joint (locked or active) is

also provided.

Example



217

The following example shows the use of the RRIKJPartial class to

compute the inverse position solution for a seven DOF robot arm. First, an

instance of the RRIKJPartial class is created by supplying the DH parameters of

the robot under consideration. By default, the first joint of this robot is locked

and the others are active. Additionally, an RRFKPosition object is created to

evaluate the starting hand position based on the initial joint configuration. This

starting hand position provides a base point for the inverse kinematics. After that,

the RRIKJPartial object is used to compute the inverse position solution for

tracking a straight line path in the positive ‘X’ direction. The interface for the

RRIKJPartial class is listed in Section B.5.6.

RRFKPosition fowkin(“rr7.dh”);// create a forward position object for the robot

// whose DH parameters are described in “rr7.dh”

RRVector initialJoints(7); // create a vector for holding initial joint

// configuration

RRVector jointSolution(7); // create a vector for holding the solution of

// the inverse kinematics

RRVector lockedJoints(1); // create a vector for holding the number of the

// locked joint. This vector is of

// size = DOF - 6

RRVector lockedValues(1); // create a vector for holding the positions

// of the locked joint. This vector is of

// size = DOF - 6 initialJoints[0] = 30.0; // set initial value of joint 1 to 30 degrees

initialJoints[2] = -60.0; ; // set initial value of joint 3 to -60 degrees

initialJoints[4] = 45.0; ; // set initial value of joint 5 to 45 degrees



initialJoints *= DEGTORAD; // convert angles from degrees to radians

hand = *fowkin.GetHandPose(initialJoints); // compute the starting hand location

RRIKJPartial invkin(“rr7.dh”, initialJoints); // create an inverse kinematics

// object for the robot whose DH

// parameters are given in “rr7.dh.” The

// first joint is locked by default when this

// object is created lockedJoints[0] = 1; // set the locked joint to joint 2

lockedValues[0] = initialJoints[1]; // set the position of the locked joints

for(int I = 0; I < 30; I++){ // increment the ’X’ coordinate of the

hand.at(0,3) += 0.1; // current hand location by 0.1 30 times

if(invkin.GetJointPosition(hand, jointSolution) > 0){ // and compute the inverse position



218

cout << jointSolution * RADTODEG << endl; // solution and print it

}else{ // if no solution

cout << “singularity” << endl; // print “singularity”

}

}

5.3.5.7. Generate Options

The generate options component applies only to redundant arms and its

primary functionality is to support the generation of null-space joint options based

on a given end-effector location. In other words, once an end-effector location is

supplied to this component, it returns a set of joint angle solutions that satisfy the

end-effector constraints. This set of solutions is also known as the null-space orthe self-motions. The technique used for the generation of this self-motion is

described in detail in Chapter Three. This technique uses a hybrid formulation

that is based on a combination of a six DOF generalized inverse and the direct-

search technique (see Chapter Three for details). Using this scheme, a set of local

null-space joint options can be generated. Performance criteria can then be used

to rank this set of joint-space options. The best option can then be used as the

inverse kinematics solution. This component is slated for future development,

though its key functionality and its attributes have been finalized. These are:

• This component is created by supplying the DH parameters of the redundant

arm for which joint-space options have to be generated. Additionally, a

starting joint configuration of the arm and an error bound are also supplied.

• The key input into this system is an end-effector position and orientation. The

output is a set of joint-space options that satisfy the input position and

orientation.

• The number of options that are generated can be controlled. As this

component implements the hybrid scheme (see Chapter Three for details), it

supports simple, factorial, and exhaustive approaches to joint-space options

generation.



219

• The hybrid scheme uses a generalized inverse for computing the inverse

position solution for a six DOF substructure of the redundant arm. The

functionality to compute this sub-structure inverse is supported by

RRIKJPartial class. Thus, the RRIKJPartial class is contained within the

generate options component.

• Functionality is provided to perform direct-search on the joints to generate a

set of joint-space options.

• Though this component does not output an inverse position solution, it is still

a part of the inverse kinematics domain. This is because of the algorithmic

compatibility of this component with the inverse kinematics domain.

• This component is given the name RRGenerateOptions and is derived from

the RRBase class.

5.3.5.8. Fault Tolerant Generate Options

This component is an extension to the generate options component

described in the previous section. The purpose of this component is to add level

III fault-tolerance to the generate options component. Level III fault-tolerancerelies on redundancy to counteract joint failure [Sreevijayan and Tesar, 1994].

Thus, this component adds the functionality to allow for joint-space options

generation in the event of joint failure. The key functionality and attributes of

this component have been finalized and are discussed below:

• This component is an extension of the generate options component and is thus

derived from it. All the functionality of the generate options component is

inherited by this component.

• The name of this component is RRFTGenerateOptions.

• An RRFTGenerateOptions object can be created by supplying the DH

parameters of the redundant arm for which joint-space options have to be

generated.



220

• The key input into this system is an end-effector position and orientation. The

related output is a set of joint-space options.

• Additional functionality is provided that allows for inactivating a particular

joint or joints of the robot. The inactivating of a joint is analogous to a joint

failure. A total of n-6 joints can be failed. Here n is the DOF of the robot.

• When a joint is failed, it is excluded from the six DOF substructure that is

used for the generalized inverse. Additionally, the failed joint is also not used

to generate perturbations when the direct-search algorithm is applied to the

remaining joints.

• It should be noted that the number of joint-space options generated may go

down as the number of failed joints go up. For example, for a seven DOF

robot, if one joint fails, the number of options that can be generated will

become one. This is because, all the active joints will be used to satisfy end-

effector constraints and no joint will be available for the application of the

direct-search.

5.3.5.9. Hybrid Inverse

This component implements a criteria-based generalized inverse

kinematics scheme for redundant robots. This scheme uses a combination of the

resolved rate motion control technique, the direct-search technique, and

performance criteria to solve the inverse kinematics solution. Details of this

scheme are discussed in Chapter Three. The key attributes and functionality of

this component are discussed below:

• As this component implements an inverse kinematics scheme at the position-

level, it is derived from RRIKPosition.

• The name of this component is RRIKHybrid.



221

• The DH parameters of the redundant arm and a performance criteria fusion

object (see Section 5.3.6.5) are used as key inputs to create an RRIKHybrid

object.

• This component contains an RRGenerateOptions object. The

RRGenerateOptions object is used to generate a set of joint-space options for

a given end-effector position and orientation. The input performance criteria

fusion object is used to rank these options. The best option then constitutes

the inverse position solution.

• Additional functionality is defined for setting the tool-point and setting the

robot location.

5.3.5.10. Fault Tolerant Hybrid Inverse

This component extends the hybrid inverse to support level III fault-

tolerance. Thus, this component can be used to compute a performance criteria-

based generalized inverse for redundant arms that support fault-tolerance. Thus,

this component actively uses redundancy to counteract the effects of a fault in a

robot arm. The key attributes and functionality of this component are givenbelow:

• The C++ class name for this component is RRIKFTHybrid.

• As this component is an extension of the hybrid inverse, RRIKFTHybrid is

derived from RRIKHybrid.

• Internally, this component contains an RRFTGenerateOptions object. The

embedded RRFTGenerateOptions object is used to generate a set of joint-

space options keeping into account the failed joints. The joint-space options

are ranked using the input performance criteria.

• Additional interface added to this class allows the user to specify the failed

joint and the position of the failed joint. Up to n-6 (n > 6) joints can be

specified as failed, where n is the DOF of the robot.



222

5.3.5.11. Closed-Form Inverse

The previous sections discussed the analysis and design of componentsthat support generalized kinematics. Closed-form kinematics offers the

advantages of execution speed and robustness over generalized kinematics. Thus,

an abstract data type was developed that supported closed-form inverse

kinematics. For this purpose, a new data type called RRIKClosedForm was

derived from RRIKPosition. This class acts as a base class for all closed-form

inverse position solutions. As this class encapsulates closed-form solutions, the

functionality for checking the maximum number of iterations, setting the tool-

point, and the maximum error is redefined. Functionality for checking the

maximum number of iterations and maximum error is not needed here because it

is a closed-form solution. A closed-form inverse always produces a zero error

solution (barring numerical error) unless the robot is in a singular configuration.

5.3.5.12. Puma Geometry Inverse

RRIKPumaGeometry is derived from RRIKClosedForm and it

implements a closed-form inverse position solution for wrist point robots thathave a similar geometry to the PUMA 560 industrial robot.

5.3.5.13. Summary of The Inverse Kinematics Domain


software components developed as a part of the inverse kinematics domain.

Components developed in this domain supported generalized and closed-form

inverse kinematics at the position and velocity-level. The components developed

in this domain were part of a class hierarchy that is shown in Figure 5.5.



223

RRIKPosition

RRIKVelocity

RRIKJacobian

RRIKJForGTSix RRIKJPartialRRIKJForSix

RRIKClosedForm

RRIKPumaGeometry

RRIKHybrid

RRIKFTHybrid

RRBase

RRGenerateOptions

RRFTGenerateOptions

Figure 5.5: Class Hierarchy for the Inverse Kinematics Domain.

5.3.6. Performance CriteriaThe inverse kinematics solution of redundant robot arms has infinite

solutions. This property of redundant arms can be used to appropriately select a

solution that maximizes a certain performance criterion or a set of performance

criteria. Initially, five general categories of these performance criteria have been

identified. These are constraint, geometric, inertial, compliance, and kinetic

energy [Hooper, 1994]. This domain includes components for performance

criteria and criteria fusion. Table 5.7 lists and gives a brief description of the key

software components developed as a part of the performance criteria domain.

These components are described in detail in the following sections.

Performance Criteria Description



224

Components

Performance Criteria ⇒ Abstract component that defines theinterface and some functionality for variousperformance criteria.

⇒ Includes functionality for sorting

Maximize Joint Range Availability ⇒ Component that ranks various joint-spaceoptions based on the joint range availabilityor distance from joint limits

⇒ This is an extension of performance criteria

Minimize Joint Velocity ⇒ Component that ranks various joint-spaceoptions based on the joint velocities


Maximize Measure of Transmissibility ⇒ Component that ranks various joint-spaceoptions based on distance from singularity


Criteria Fusion ⇒ Component for fusing various criteria andcoming up with an overall ranking of joint-space options

⇒ Includes functionality for sorting⇒ Uses the weighted sum technique described

in Chapter Three

Table 5.7: Key Components of the Performance Criteria Domain.

5.3.6.1. Performance Criteria

The purpose of this component is to provide functionality that is common

to the development of specific performance criteria. Analysis and design

considerations for this component are given below:

Analysis

• The key input for this component is a set of joint angle solutions that satisfy a

particular end-effector constraint. The output of this component is a ranking

of the input solutions based on some relevant criteria.

• The functionality to compute a criteria value is specific to a particular criteria

and is left to the derived classes.



225

• A sorting algorithm has to be used in this component for ranking various

options.

• Each criteria has a weight associated with it. Additionally, a criteria can be

maximized or minimized.

Design

• This component was given the name RRPerformanceCriteria.

• RRPerformanceCriteria is implemented as an abstract data type because it

only provides an interface for computing criteria value. The functionality is

left to the derived classes.

• RRPerformanceCriteria is derived from RRBase.

• The functionality to sort solutions is provided in this class and is used by all

derived classes. The quick-sort algorithm is used for ranking input options

[Horowitz and Sahni, 1993].

• Functionality is provided for accessing and setting the weight of a criterion,

and setting whether a criterion needs to be maximized or minimized.

Section B.6.1 outlines the interface of the RRPerformanceCriteria class.

5.3.6.2. Maximize Joint Range Availability

This component implements a constraint criteria that is based on

maximizing the Joint Range Availability (JRA). The analysis and design issues

for this component are given below:

Analysis

• Maximize Joint Range Availability is a type of performance criteria. This

implies an IS-A relationship.

• The JRA is represented and formulated as follows:



226

JRA =

i i

ii=

nθ θ

θ

−

∑

~

max

2

21 ,

where i is the joint displacement, iθ

~

is the mid-range displacement and i max

is the displacement at the joint limit. This criterion seeks to select a joint

solution that keeps the joint displacements as near as possible to the midpoints

of their travel. This formulation is used to compute the criteria value.

Design

• This component is implemented as a C++ class and is named

RRPCAvoidLimits.

• As RRPCAvoidLimits is a type of performance criteria, it is derived from

RRPerformanceCriteria.

• The functionality for ranking various joint-space options, setting and

accessing the weight of a criteria, etc. is inherited from


• The RRPerformanceCriteria class virtual method for computing criteria value

is defined in this class. It computes the criteria value based on the JRA.

Example

The following example shows a use of the RRPCAvoidLimits class to

rank various joint-space options based on their distance from joint limits. First an

RRPCAvoidLimits object is created by supplying the joint limits data for the

robot in question. Based on this joint limit data, the RRPCAvoidLimits object

can be queried for joint range and joint median. Further on, this object is used to

rank a set of joint-space options. The joint-space option that is furthest from the

joint limits (or closest to the median) is ranked at the top. Section B.6.2 outlines

the interface of this class.



227

/* create a matrix for holding the solutions that have to be ranked. Each row of this matrix

holds a joint solution and the last element of each row holds the measure of manipulability of

the respective solution */

RRMatrix solutions(8,3);

/* compute a set of three joint-space options and store them in ‘solutions’ */

RRCriteriaValue *critVals;

RRPCAvoidLimits jra(“limits.dat”, 3,); // create a criteria object that maximizes

// the joint range availability for a robot

// whose joint limits are specified in the

// “limits.dat” file

cout << jra.GetJointRange() << endl; // print out the joint range of each joint

cout << jra.GetJointMedian() << endl; // print out the median of each joint

jra.SetWeight(2); // set weight of this criteria to 2

jra.PickSolution(solutions, critVals); // for all the joint-space options specified in

// ‘solutions’, compute the criteria values and rank

// the options based on these criteria values and

// return a pointer to these ranked options in // ‘critVals’

5.3.6.3. Minimize Joint Velocity

This component implements a criteria that tends to minimize joint

velocities. The analysis and design issues for this component are given below:

Analysis

• Minimize joint velocity measure (JVM) is a type of performance criteria.

This implies an IS-A relationship.

• A measure of the joint velocity is computed by taking an inner product of the

difference between a joint solution and the current robot joint position. The

solutions are then ranked in ascending order with the solution that provides

the minimum joint velocity measure (JVM) at the top. The JVM computation

is formulated as follows:

( )

JVM =

i icurr i=

n

n

θ θ −

∑ 2

1

,

where i is the joint displacement of the ith joint, and icurr θ is the current position

of the ith joint.

Design



228

• This component is implemented as a C++ class and is named

RRPCMinimizeVelocity.

• As RRPCMinimizeVelocity is a type of performance criteria, it is derived

from RRPerformanceCriteria.


accessing the weight of a criteria, etc. is inherited form


• Additional functionality is provided for setting the current joint position of the

robot. This current position is used in computing the JVM for each joint-

space option.

• The RRPerformanceCriteria class virtual method for computing the criteria

value is defined in this class. It computes the criteria value based on the JVM.

Example

The following example shows a use of the RRPCMinimizeVelocity class

to rank various joint-space options based on their respective joint velocities. First

an RRPCMinimizeVelocity object is created by supplying the current joint

position of the robot. After that, joint-space options are supplied and the velocity

measure for each option is computed by subtracting each option from the current

joint position and taking the norm of the result. The joint-space option that

results in minimum joint velocity is ranked at the top.


holds a joint solution and the last element of each row holds the measure of manipulability of




RRVector currentPos; // current robot joint position

RRCriteriaValue *critVals; RRPCMinimizeVelocity jvm(currentPos, 3); // create a criteria object that

// minimizes the joint velocities

jvm.PickSolution(solutions, critVals); // for all the joint-space options specified in



// return a pointer to these ranked options in



229

// ‘critVals’

5.3.6.4. Maximize Measure of Transmissibility

This component implements a criteria that seeks to select joint solutions

that have the maximum measure of transmissibility (MOT). The analysis and

design for this component are given below:

Analysis

• Maximize measure of transmissibility is a type of performance criteria. This

implies an IS-A relationship.

• MOT can be calculated as:

( )MOT

det T

=JJ

n 2

where J is the Jacobian matrix for a given joint position.

• The input joint solutions are sorted in descending order of MOT for each

solution.

Design

• This component is implemented as a class and is named

RRPCMaximizeMOT.

• As RRPCMaximizeMOT is a type of performance criteria, it is derived from



accessing the weight of a criteria, etc. is inherited from


• The RRPerformanceCriteria class virtual method for computing the criteria

value is defined in this class. It computes the criteria value based on the

MOT.

Example



230

The following example shows a use of the RRPCMaximizeMOT class to

rank various joint-space options based on their respective measure of

transmissibility. First an RRPCMaximizeMOT object is created. After that,

joint-space options and their measure of transmissibility are supplied to the

RRPCMaximizeMOT object. The joint-space option with the maximum measure

of transmissibility is ranked at the top. Section B.6.4 outlines the interface of the

RRPCMaximizeMOT class.


holds a joint solution and the last element of each row holds the measure of transmissibility of


RRMatrix solutions(8,3); /* compute a set of three joint-space options and store them in ‘solutions’ */


RRPCMaximizeMOT mot(3); // create a criteria object that

//maximizes the measure of transmissibility

mot.PickSolution(solutions, critVals); // for all the joint-space options specified in



// return a pointer to these ranked options in

// ‘critVals’

5.3.6.5. Performance Criteria Fusion

The previous sections showed the software components developed forsingle criterion-based decision making. However, in a “real-world” application,

multiple criteria are actively used in decision making. For example, in a “real”

application, it is equally important to avoid joint limits and to avoid singularities.

Criteria fusion is one means of incorporating multiple criteria. This software

component implements a scheme for criteria fusion that is based on a weighted

sum (see Chapter Three for more details). The analysis and design issues faced in

the development of this component are discussed below:

Analysis

• The two key inputs for this software component are a set of performance

criteria and a set of joint-space options. The key output of this system is an



231

overall ranking of the joint-space options based on the set of input

performance criteria.

• The first step in finding the overall ranks of all the solutions is to rank all of

them for each performance criterion. Then, based on the weight of each

performance criterion and the ranked solutions for that criterion, a solution is

picked that best satisfies the set of all performance criteria. This is done as

follows:

R w Rt

n

i in

i

m

= ∑=

( )1

3.9

where,

n = the number of solutions under consideration,

iw = the weight of criterion i,

Ri

n = the rank of solution n for criterion i, and

t n R = the overall rank for solution n.

• Functionality has to be supported for sorting of the fused criteria values.

Design

• This component was implemented as a C++ class and was named

RRPCFusion and is derived from RRBase.

• Functionality is provided to add performance criteria and for sorting criteria

values.

Example

The following example shows a use of the RRPCFusion class to rank

various joint-space options based on a set of input performance criteria. First an

RRPCAvoidLimits and an RRPCMinimizeVelocity objects are created. Then anRRPCFusion object is created by passing it the two performance criteria objects

that were created earlier. After that, a set of joint-space options are supplied to

the RRPCFusion object. The RRPCFusion object then ranks these options based



232

on a fusion of the input performance criteria set. Section B.6.5 outlines the

interface of the RRPCFusion class.


holds a joint solution and the last element of each row holds the measure of transmissibility of




RRVector currentPos; // current robot joint position


RRPCAvoidLimits jra(“limits.dat”, 3,); // create a criteria object that maximizes

// the joint range availability for a robot

// whose joint limits are specified in the

// “limits.dat” file

RRPCMinimizeVelocity jvm(currentPos, 3); // create a criteria object that

// minimizes the joint velocities RRPerformanceCriteria* critArray[2]; // create an array for holding pointers

// to criteria objects

critArray[0] = &jra; // assign criteria ‘jra’ to element 0

critArray[1] = &jvm; // assign criteria ‘jvm’ to element 1

RRPCFusion fuse(critArray, 2, 3); // create a criteria object that

// will fuse a set of criteria

fuse.PickSolution(solutions, critVals); // for all the joint-space options specified in

// ‘solutions’, compute the overall criteria values

// and rank the options based on these criteria

// values and return a pointer to these ranked

// options in ‘critVals’

5.3.6.6. Summary of The Performance Criteria Domain


components developed as a part of the performance criteria. Components

developed in this domain supported abstractions for performance criteria and

criteria fusion. Some specific performance criteria were also developed. The

components developed in this domain were part of a class hierarchy that is shown

in Figure 5.6.



233

5.3.7. Generalized Dynamics

Robot inverse dynamics involves computing the joint torques (or forces

for prismatic joints) based on a desired robot position, joint velocity, joint

acceleration, and forces and torques at the robot hand. Various techniques have

been developed for computation of inverse dynamics. One of the most

computationally efficient is the recursive Newton-Euler technique [Craig, 1986].

Thomas and Tesar [1982] also developed a Lagrangian dynamic modelingtechnique for serial manipulators that is based on influence coefficients.

Kinematic influence coefficients are based solely on the geometry of the system.

This technique is useful for design as it provides detailed information about the

system behavior and can thus be used for determining load and size of links and

actuators [Thomas and Tesar, 1982]. Both Newton-Euler [Craig, 1986] and the

technique proposed by Thomas and Tesar [1982] have been used to build

software components that adhere to a standardized interface and promote reuse.

These components and their key functionality is outlined in Table 5.8.

RRPerformanceCriteria

RRPCAvoidLimitsRRPCMaximizeMOT

RRPCFusion

RRPCMinimizeVelocity

RRBase

Figure 5.6: Class Hierarchy for the Performance Criteria Domain.



234

5.3.7.1. Inverse Dynamics

This component implements an abstract data type that defines the interface

for computing the joint torques based on given joint position, velocity, and

acceleration. This component is implemented as a C++ class and is named

RRInvereseDynamics. This class takes as arguments the link masses, inertia

tensors, and location of center of gravity of each link. As this is an abstract data

type, the functionality for computing the joint torques is specified by the derived

classes. Section B.7.1 outlines the interface for this class.

5.3.7.2. Newton-Euler Recursive Dynamics

Newton-Euler recursive dynamics is an efficient means of computing the

inverse dynamics of serial robots. However, this technique does not give detailed

Inverse Dynamics Components Description

Inverse Dynamics ⇒ Abstract component that defines theinterface for inverse dynamics

⇒ This interface includes the computation of joint torques based on a given jointposition, velocity, and acceleration

Newton-Euler Recursive Dynamics ⇒ The component defines the functionality forcomputing the inverse dynamics using therecursive Newton-Euler technique

⇒ This is a type of inverse dynamics

Lagrangian Dynamics ⇒ This defines the interface and functionalityfor computing joint torques due to velocity,acceleration, link loads and end-effector

loads. Additionally, overall effectiveinertia matrix and inertia power matricescan be computed (see Thomas and Tesar[1982] for details)

⇒ This is a type of inverse dynamics

Table 5.8: Key Components of the Inverse Dynamics Domain.



235

information about system inertia properties. The key analysis and design issues

faced in the development of this component are given below:

Analysis

• Newton-Euler inverse dynamics is a type of inverse dynamics.

• The evaluation of the forward position solution is required for recursive

Newton-Euler.

• Details of the recursive Newton-Euler technique are provided in Craig [1986].

Design

• This component was given the name RRIDNewtonEuler.

• This component being a type of inverse dynamics implies an inheritance

relationship. Thus, RRIDNewtonEuler is derived from RRInverseDynamics.

• As the forward position solution is required to compute the Newton-Euler

inverse dynamics solution, an RRFKPosition object is contained within this

component.

Example

The following example shows the use of RRIDNewtonEuler to compute

the joint torques of a seven DOF manipulator. In the example shown, the robot is

made to follow an arbitrary trajectory defined by joint positions. The joint

velocities and accelerations are computed by finite differences. A constant force

and torque is also applied to the robot end-effector. The joint torques are

computed and printed. Section B.7.2 outlines the interface of this class.

RRVector pos(7), vel(7), acc(7), torques(7), handForce(3), handTorque(3);

RRVector prevPos(pos), prevVel(vel);

// create an RRIDNewtonEuler object for a robot whose DH parameters are described in the

// file”alpha.dh,” the center-of-gravity and mass in “alpha.cgm,” and the link inertias in

// “alpha.ine.” RRIDNewtonEuler dynamic("alpha.dh", "alpha.cgm", "alpha.ine");

double timeDelta = 0.04; // a set point is generated every 0.04 seconds

handForce[0] = 1.0; // a force of 1.0 unit in the X direction

handTorque[2] = 0.2; // a moment of 0.2 units about the ‘Y’ axis

for(int I = 0; I < 30 ; I++){

pos += 0.1; // move all joints by 0.1 radians



236

vel = (pos - prevPos)/timeDelta; // compute joint velocity by finite differences

acc = (vel - prevVel)/timeDelta; // compute joint accelerations by finite differences

// compute the joint torques

torques = dynamic.GetJointTorques(pos, vel, acc, handForce, handTorque);

cout << torques << endl; // output the computed torques

prevPos = pos; // update the previous position

prevVel = vel; // update the previous velocity

}

5.3.7.3. Lagrangian Dynamics

The Newton-Euler dynamics described in the previous section does not

provide detailed information about the overall system inertia. An inverse

dynamics scheme formulated by Thomas and Tesar [1982] uses first and second-

order kinematic influence coefficients to efficiently compute the inverse

dynamics solution and to describe system inertia. This information is useful in

robot design [Hill, 1996] and real-time operation with performance criteria

[Hooper, 1994]. For example, the effective inertia matrix can be used in a

criteria-based inverse kinematics solution that minimizes the total kinetic energy

of the system [Hooper, 1994]. This software component implements the Thomas

and Tesar [1982] approach to inverse dynamics. The analysis and design issues

faced in the development of this component are given below:

Analysis

• Lagrangian dynamics is a type of inverse dynamics.

• The Thomas and Tesar [1982] approach relies on first and second-order

rotational and translational kinematic influence coefficients. This implies a

USES-A relationship.

•

Functionality supported by this component should include the computation of the overall effective system inertia, the inertia power matrices, the joint

torques due to loads on links, the joint torques due to gravity, the joint torques



237

due to joint velocities, the joint torques due to joint acceleration, and the

overall torques.

Design

• This component was given the name RRIDLagrange and is derived from

RRInverseDynamics.

• The interface for this component takes as arguments the first and second-order

kinematic influence coefficients. These coefficients are used in the

computation of the joint torques and the inertia matrices.

• Another means of supplying this component with the kinematic influence

coefficients would have been to embed an RRFKAcceleration object within

itself. However, it was decided to compute the kinematic influence

coefficients externally as they could then be made available to other software

components for use. This can avoid their recomputation. Also, a simpler

inverse dynamics component that contains an RRFKAcceleration object and

an RRIDLagrange object inside it can be assembled if needed.

• Functionality is defined for joint torque and system inertia matrices

computation.

Example

The following example shows the use of RRIDLagrange and

RRFKAcceleration to compute the effective inertia matrix, the inertia power

matrices, and the joint torques due to gravity and joint velocity. First an

RRFKAcceleration object is created by supplying the DH parameters of a three

DOF robot. Then an RRIDLagrange object is created by supplying the link

center-of-gravity, their mass, and their inertia. The first and second-order

influence coefficients are then computed using the RRFKAcceleration object and



238

their output is used by RRIDLagrange to solve the inverse dynamics problem.

Section B.7.3 outlines the interface of the RRIDLagrange class.

RRFKAcceleration fka("three.dh"); // create an RRFKAcceleration object for the three

// DOF robot whose DH parameters are given in

// “three.dh”

RRVector pos(3); // create a vector of size three to hold the joint positions

RRVector vel(3), acc(3); // create two vectors to hold the velocity and acceleration

RRVector force(3), torq(3); // create vectors to specify hand forces and torques

RRVector gtorques(3); // create a vector to hold the gravity torque

RRVector vtorques(3); // create a vector to hold the velocity torque

RRMatrix cg(3, 3); // create a matrix to hold the center of gravity of each link

pos[0] = 85.0; pos[1] = 80.0; pos[2] = 240.0; // set joint position of the robot

pos *= DEGTORAD; // convert degrees to radians

cg(2,0) = .17; // center of gravity for link 1 is [0, 0, .17]cg(0,1) = 0.21; // center of gravity for link 2 is [.21, 0, 0]

cg(0,2) = .17; // center of gravity for link 1 is [.17, 0, 0]

// Create an RRIDInverseDynamics object by supplying the DOF, link masses

// and center-of-gravities, and the link inertia.

RRIDLagrange dn(3,"three.cgm","three.inr");

fka.SetLinkPoints(cg); // inform the fka object about the coordinates about which the

// translational first-order influence coefficients have to be

// computed

fka.GetHandPose(pos); // compute the forward position solution and update the state

// of the global transformation matrices based on the joint

// position of the robot

RRTensor *rg = fka.GetRotationalGfunctions(); // compute the rotational G functions

RRTensor *tg = fka.GetTranslationalGfunctions(); // compute the translational G functions

RRTensor** rh = fka.GetRotationalHfunctions(); // compute and get the rotational

// H functions

RRTensor** th = fka.GetTranslationalHfunctions(); // compute and get the

// translational H functions

RRXform* globalTs = fka..GetAllGlobalTransformations(); // get all the global

// transformation matrices that were

// previously computed in the call to

// GetHandPose

cout << *dn.GetIstar(globalTs, rg, tg) << endl; // compute and print the effective system

// inertia

RRTensor* pstar = dn.GetPstar(rg,tg,rh,th) // compute and get the inertia power matrix

dn.GetGravityTorques(tg, gtorques); // compute and get the gravity torques

dn.GetVelocityTorques(vel, vtorques); // compute and get the velocity torques

5.3.7.4. Summary of The Inverse Dynamics Domain


software components developed as a part of the inverse dynamics domain.



239

Components developed in this domain supported generalized inverse dynamics

using Newton-Euler and Lagrangian dynamics. These components were part of a

class hierarchy that is shown in Figure 5.7.

5.3.8. Generalized Deflection Modeling

Industrial robots lack in stiffness primarily due to bending and twisting of

the links and deflection in the joints. This compliance in the mechanical structure

results in an erroneous end-effector position and orientation. However, if the

deflection at the end-effector can be predicted, the system controller could

compensate for this deflection. This software component defines the interface for

deflection modeling of serial arms. This interface uses the kinematic influence

coefficients to compute the deflection at the end-effector. Additionally, this

component also defines the interface for computing a generalized spring

representation of the robot. Fresonke et al. [1988] discuss the details of this

methodology. The key analysis and design issues faced in the development of

this component are discussed below:

Analysis

• The key functionality of this component is to compute the deflection of the

end-effector under gravity and inertial loads.

RRInverseDynamics

RRIDNewtonEulerRRIDLagrange

RRBase

Figure 5.7: Class Hierarchy for the Inverse Dynamics Domain.



240

• Deflection at the end-effector can be attributed to two key factors. These are,

the deflection due to deformation of links and the deflection due to

compliance in joints. The interface for this component should support the

separate computation of these deflections.

• A compliant serial robot can be represented as a generalized spring. This

generalized spring matrix would be dependent on the joint configuration of

the robot. The interface for this component should support the computation of

the generalized spring matrix.

• The deflection model relies on the first-order kinematic influence coefficients

and the computation of the joint loads. The kinematic influence coefficients

can be computed using the RRFKVelocity abstraction and the joint torques

can be computed using any of the components in the inverse dynamics

domain.

Design

• As this component just defines the interface for deflection modeling, it is

implemented as an abstract data type.

• This component is given the name RRDeflection.

• RRDeflection uses components from the forward kinematics and the inverse

dynamics domain.

• This component takes as inputs the flexibility matrices for each link and the

compliance values for each joint.

• Functionality for this component has to be supplied by derived classes.

Example

The following example shows the use of the interface of the RRDeflectionabstract class. A RRFKVelocity object is used in this example to compute the

first-order rotational kinematic influence coefficients. The RRIDNewtonEuler is

used to compute the joint torques. The computed first-order kinematic influence



241

coefficients and the joint torques are then used to compute the deflection in the

links and the actuators respectively. Section B.8.1 outlines the interface of the

RRDeflection class.

RRFKVelocity fkv("three.dh"); // create an RRFKVelocity object for the three

// DOF robot whose DH parameters are given in

// “three.dh”

// create an RRIDNewtonEuler object for a robot whose DH parameters are described in the

// file”three.dh,” the center-of-gravity and mass in “three.cgm,” and the link inertias in

// “three.ine.”

RRIDNewtonEuler dynamic("three.dh", "three.cgm", "three.ine");

// create a RRDeflection object by specifying the degrees-of-freedom, the link flexibility

// matrices and the joint stiffness

RRDeflectiondeflect(fkv.GetDOF(), “linkFlex.dat”, “jointFlex.dat”);

RRVector linkDeflect(3); // create a vector for holding link deflections

RRVector jointDeflect(3); // create a vector for holding joint deflections

double timeDelta = 0.04; // a set point is generated every 0.04 seconds

handForce[0] = 1.0; // a force of 1.0 unit in the ‘X’ direction

handTorque[2] = 0.2; // a moment of 0.2 units about the ‘Y’ axis

for(int I = 0; I < 30 ; I++){

pos += 0.1; // move all joints by 0.1 radians

vel = (pos - prevPos)/timeDelta; // compute joint velocity by finite differences

acc = (vel - prevVel)/timeDelta; // compute joint accelerations by finite differences

// compute the joint torques

torques = dynamic.GetJointTorques(pos, vel, acc, handForce, handTorque);

fkv.GetHandPose(pos); // compute the forward position solution and update the state

// of the global transformation matrices based on the joint

// position of the robot // compute the rotational G functions

RRTensor *rg = fkv.GetRotationalGfunctions();

deflect.GetDeflectionDueToLinks(rg, linkDeflect); // compute deflection due to links

deflect.GetLocalJointDeflection(torques, jointDeflect); // deflection due to joints

}

5.3.8.1. Summary of The Generalized Deflection Modeling Domain

The previous section discussed the analysis and design details of the

component developed as a part of the deflection modeling domain. The class

hierarchy for the component developed in this domain is shown in Figure 5.8.



242

5.3.9. Input/Output Devices

This domain includes all software components that are used for input or

output operations. This domain does not directly fit into the operational software

layer. However a preliminary development of this domain was essential for the

testing of the operational software. Using components from this domain, the

applications developer can interface to external hardware (such as, robots) and

test the operational software components that are being developed. Some

components for this domain were developed as a part of this research. Other

components were developed by applications developers [Rackers, 1996] and

some were obtained from Sandia National Laboratories. The key components in

this domain and their basic functionality are listed in Table 5.9. The following

section discusses the Keyboard component that was developed as a part of this

research.

Input Output Devices Description Physical I/O ⇒ Abstract component that defines the interface for all

physical input output devices⇒ Developed by Sandia National Labs

GPIB board ⇒ The component defines the functionality for using ahardware board that supports the GPIB communicationprotocol (see Chapter Four for details on GPIB)

⇒ Functionality is included for initializing the board, setting itsattributes, and for performing read and write operations

⇒ This is a type of Physical I/O device⇒ Developed by Sandia National Labs

RRDeflection

RRBase

Figure 5.8: Class Hierarchy for the Deflection Modeling Domain.



243

Port I/O ⇒ The component defines the functionality for using ports toperform input-output operations.

⇒ Functionality is included for initializing the port, setting itsattributes, and for performing read and write operations

⇒ This is a type of Physical I/O device⇒ Developed by Sandia National Labs

Serial Port I/O ⇒ The component defines the functionality for using serialports to perform input-output operations.

⇒ This is a type of Port I/O⇒ Developed by Sandia National Labs

Puma Serial Port I/O ⇒ The component defines the functionality for using a serialport to interface to the controller of a PUMA 560 robot

Teach Ball Serial Port I/O ⇒ The component defines the functionality for using a serialport to interface to a Teach Ball

Button Board ⇒ This component defines the functionality and interface toaccess the state of a set of switches that are connected to theVME bus using digital I/O. Developed by Rackers [1996]

Force Torque Sensor ⇒ This component defines the functionality to interface to aforce-torque sensor. Developed by Rackers [1996]

Robot Input Output ⇒ This component defines the functionality for interfacing tothe servo-layer of the Robotics Research dual-arm robot.Developed by Rackers [1996]

Keyboard ⇒ This component defines the functionality for interfacingwith the keyboard as an input device in blocking and non-blocking modes (see Section 5.3.9.1)

Table 5.9: Key Components of the Input/Output Devices Domain.

5.3.9.1. Keyboard

This keyboard software component supports functionality for efficiently

using the keyboard as an input device for controlling robots. Additionally, this

component provides a simple interactive interface that can assist in program

debugging. For example, during the development of the inverse kinematics

components, it was necessary to input different end-effector configurations fortesting the software. For this purpose, the keyboard was used in a manner similar

to a teach pendant. Using this approach, pressing different keys resulted in the

interactive generation of end-effector set-points. Additionally, using the



244

keyboard, a physical robot could be controlled similarly. The key analysis and

design issues faced in the development of this component are discussed below:

Analysis

• The key functionality of this component is to provide the ability to test the

state of a key. That is, whether a key is pressed or not.

• The user should be able to test the state of a key in blocking and non-blocking

mode. Under blocking mode, the program waits until a key is pressed. Under

non-blocking mode, the program just polls the keyboard and checks the state

of the keys (for details see [WindRiver Systems, VxWorks Programmer’s

Guide]).

• The keyboard has to be reconfigured for non-canonical character processing.

Canonical character processing relies on specific formats for character input.

This is the default mode. For example, under canonical processing, a carriage

return has to be input after a character is input. Under non-canonical (also

called raw mode), only a character has to be input. The input character does

not have to be followed by a carriage return (for details on canonical and raw

character processing see [WindRiver Systems, VxWorks Programmer’s

Guide]).

Design

• This component was given the name RRKeyboard and was derived from

RRBase.

• It supports the functionality to set the keyboard to non-blocking mode and the

character processing to raw mode.

•

The software implementation for this component is specific to the operatingsystem. Currently, VxWorks, UNIX, and Windows NT are supported.

Example



245

The following example shows the use of the keyboard in blocking mode

with raw character processing. The program loops and prints out the value of the

key that was pressed. The program quits when the escape key is pressed. Section

B.9.1 outlines the interface of the RRKeyboard class.

#define ESCAPE 27 // escape key is ASCII code 27

RRKeyboard keyboard(RRKeyboard::BLOCK); // create an RRKeyboard object that puts the

// keyboard in a blocking mode

char key = 0; // the pressed key will be stored in this

while(key != ESCAPE){ // loop till the escape key is pressed

key = keyboard.GetKey(); // get the value of the key that is pressed

cout << “Key pressed = “ << key << endl; // print the key that was pressed

}

5.3.10. Controllers

This domain was developed to facilitate the integration of manual

controllers into the software testing environment. Again, this domain does not fit

directly into the operational software layer. However, the development of this

layer assisted in testing the operational software components in a manual

controller environment. Two key components were developed under this domain.

These were an abstract component for manual controllers and a component to

support the TeachBall. Software for other manual controllers like the six DOF

TOS arm and the six DOF Perforce controller has also been developed [Peterson,

1996]. However, the software for these systems is still in development and test

stages and has not been integrated into this framework. Table 5.10 lists the key

components in the controller domain. Further, the analysis and design issues

faced in the development of the TeachBall software component are discussed.



246

5.3.10.1. TeachBall

The TeachBall is a six DOF input device. Additionally, the TeachBall has

eight buttons that can be used for entering additional information. The TeachBall

can be connected to any computer that supports an RS-232 based serial port. The

software component for the TeachBall provides a general purpose interface that

can be used for any six DOF input device. The key analysis and design issues

faced in the development of this component are discussed below:

Analysis

• The key functionality of this component is to interface with the TeachBall

hardware and read its state.

• As the TeachBall uses a serial port, a serial port object is contained inside this

component.

• The user should be able to supply this component with a vector of hand

positions and orientations, and this component should be able to update this

vector based on the TeachBall movement.

Design

• This component was given the name RRTeachBall and was derived fromRRController.

• RRTeachBall contains an RRTeachBallSerialPort object.

Controllers DescriptionController ⇒ Abstract component that defines a general purpose interface

for manual controllers

TeachBall ⇒ The component defines the functionality for using aTeachBall as a manual controller

Table 5.10: Key Components of the Input Output Devices Domain.



247

• Functionality is provided to read the position of the TeachBall and also to

read the state of the buttons.

Example

The following example shows the use of the RRTeachBall manual

controller class to update a vector that specifies the end-effector location. The

updated end-effector can be input into an inverse kinematics object and the

resulting joint solution can be used to control a robot. First an RRHandPose

object is created to hold the robot hand position and orientation. Then an

RRTeachBall object is created by specifying the RRHandPose vector it will

update and the number of the serial port to which the TeachBall is connected.

Resulting this, the button status and the movements of the TeachBall are

continuously read until the first button is pressed. Section B.10.2 outlines the

interface of the RRTeachBall class.

RRHandPoserobotHand; // create a vector for holding end-effector position

// and orientation

robotHand.X() = 10.0; // set ‘X’ coordinate to 10.0

robotHand.Y() = 15.0; // set ‘Y’ coordinate to 15.0

robotHand.Z() = -5.0; // set ‘Z’ coordinate to -5.0

robotHand.Roll() = 0.05; // set Roll angle to 0.05

robotHand.Pitch() = 0.01; // set Pitch angle to 0.01

robotHand.Yaw() = -0.02; // set Yaw angle to -0.02

RRTeachBall tb(1, robotHand); // create an RRTeachBall object that uses

// serial port 1

if(!tb.Initialize()){ // initialize TeachBall and check for error

cout << DisplayError(“Initialize on TeachBall”);

}

int buttons[8]; // create an integer array for holding buttons status

tb.GetButtonStatus(buttons); // update status of the buttons from the TeachBall

while(!buttons[0]){ // loop till button 1 is pressed on the TeachBall

tb.GetCurrentHand(robotHand, buttons); // update hand and button status

cout << “Current Hand = “ << robotHand << endl; // print the current hand

}

5.3.11. Utility Components

This domain was established to support the development of the

operational software components proposed in this research. These included error



248

handling, timing, and character string encapsulation. These components and their

key functionality is outlined in Table 5.11 and details of the Timer component are

discussed in the following section.

5.3.11.1. Timer

This component encapsulates a stop-watch and is used for program

timing. Functionality is provided to start the timer, stop the timer, and to compute

the elapsed time. This component is implemented as a C++ class named

RRTimer and is derived from RRBase. Section B.11.1 outlines the interface of

the RRTimer class. An example use of the RRTimer class is shown below. In

this example, two RRTimer objects are created. One of these is used to measure

the timing of an outer for loop. The other one measures the timing of an inner for

loop. The example shows that an RRTimer object can be started and stopped

similar to a stop-watch.

double number = 1.0;

RRTimer timerA, timerB; // create two timers for program timing

timerA.Start(); // start timerA. This timer will measure

for(int I = 0; I < 10; I++){ // the elapsed time for the outer loop

timerB.Start(); // start timerB. This timer will measure

for(int j = 0; j < 3000; j++){ // the elapsed time for the inner loopnumber /= 1.1; // take up some time

}

timerB.Stop(); // stop timerB and print out the elapsed time

cout << “Elapsed time for inner loop = “ << timerB.ElapsedTime() << endl;

}

timerA.Stop(); // stop timerA and print out the elapsed time

Utility Components Description Error Handling ⇒ Sub-routines for displaying error messages

⇒ Sub-routines for displaying debugging information

String ⇒ Encapsulates a character array

Timer ⇒ Encapsulates a stop-watch⇒ Useful in program timing

Table 5.11: Key Components of the Utility Domain.



249

cout << “Elapsed time for outer loop = “ << timerA.ElapsedTime() << endl;

5.3.12. Communication Components

This domain was developed to facilitate the testing of the operational

software components that were developed as a part of this research. As discussed

in Chapter Two, the operational software layer does not include software for

interfacing with external hardware or for communication with other computers.

This software is essentially a part of the lower-most layer, that is, the real-time

control layer. However, to test the operational software components, it was

necessary to develop a rudimentary real-time and hardware interfacing software

architecture. Also, as discussed in Chapter Four, manual controller integration

was supported as a part of this research. This allowed for testing the operational

software components in a manual controller environment. Also, a graphical

simulation environment had to be supported for testing and development of the

operational software. The communications domain was developed to provide a

means of integrating the operational software components with a simulation

environment, the manual controllers, and robotic hardware. Transmission Control

Protocol (TCP) sockets and Ethernet were used for the communications (see

Chapter Four for more details). The functionality of TCP sockets was

encapsulated in three key components (the reader should refer to Brain [1994] for

details on TCP sockets). These are outlined in Table 5.12 and are discussed

below:



250

5.3.12.1. TCP

This component encapsulates the functionality of a TCP socket. This

component is implemented as an abstract data type and it provides the interface to

initialize and disconnect a TCP socket. The TCP component is given the name

RRTCP and is derived from RRBase. The interface for RRTCP class is outlined

in Section B.12.1.

5.3.12.2. TCP Client

The TCP Client component is an extension of the TCP component. This

component defines the functionality to initialize and disconnect. Additional

functionality is provided that allows for transmission of data. Two methods are

provided for transmitting data. The first one transmits data asynchronously and

does not wait for a reply. The second method relies on synchronous transmission.

In this, the client after sending a message, waits for a reply from the receiver.

This component is implemented as a C++ class and is named RRTCPClient.

RRTCPClient is derived from RRTCP. An RRTCPClient object can be created

by supplying the Internet Protocol (IP) address of the computer on which the

server is running and a port number that is used for the connection. Section

Communications Components DescriptionTCP ⇒ Abstraction that encapsulates common

functionality of all TCP connections

Server ⇒ Component that creates a server⇒ Server can be used to listen to incoming

messages and replying to them

Client ⇒ Component that creates a client⇒ A client connects to a server and sends requests

Table 5.12: Key Components of the Communications Domain.



251

B.12.2 outlines the interface of the RRTCPClient class. Given below is an

example use of the RRTCPClient class.

#define PORT 66556 // specify the port number to be used for the connection

#define SERVER_IP “129.164.123.234” // specify the IP address of the server

char toSend[] = “hello world”; // specify the string to send to the server

RRTCPClient client(SERVER_IP, PORT); // create an RRTCPClient object

if(!client.Initialize()){ // make the client connect to the server

cout << “Server on “ << SERVER_IP << “ is not running” << endl;

return;

}

client.Transmit(toSend, strlen(toSend); // send the message to the server

5.3.12.3. TCP Server

The TCP Server component is an extension of the TCP component. This

component defines the functionality to initialize and disconnect. Additional

functionality is provided that allows for receiving a message from a client and

replying to it. This component is implemented as a C++ class and is named

RRTCPServer. RRTCPServer is derived from RRTCP. An RRTCPServer object

can be created by supplying the port number that will be used by the client to

communicate. It should be noted that a server has to be running before a client

can connect and transmit data to it. Section B.12.3 outlines the interface of the

RRTCPServer class. Given below is an example use of the RRTCPServer class.

In this example, an RRTCPServer object is created and then initialized. During

initialization this object waits for a client to connect. Once connected, this object

receives data from the client and sends a reply back to the client.

#define PORT 66556 // specify the port number to be used for the connection

char recvString[20]; // character array in which the message is received

char reply[] = “acknowledge”; // specify the reply to the client

RRTCPServer server( PORT); // create an RRTCPServer object

server.Initialize(); // make the server wait for the client to connect

server.Receive(recvString, 20); // receive the message from the client server.Reply(reply, strlen(reply)); // send a reply back to the client

5.3.12.4. Summary of the Communications Domain



252


software components developed as a part of the communications domain.

Components developed in this domain supported TCP sockets based

communications. These components were part of a class hierarchy that is shown

in Figure 5.9.

5.3.13. Other Components

This domain holds all other software components that facilitate software

development. These components do not directly fit into the advanced robotics

domain but are necessary for program development. The components for this

domain were not developed as a part of this research. These components were

purchased from commercial vendors (see Table 5.13). The software for these

components came in the form of a class library (similar to what is being

developed in this research). The key sub-domains and components supported in

this domain are listed in Table 5.13.

RRTCP

RRTCPServer RRTCPClient

RRBase

Figure 5.9: Class Hierarchy for the Communications Domain.



253

Table 5.13 outlines the key functionality supported by the four class

libraries that were integrated into the software development environment. As

mentioned earlier, these libraries do not directly apply to the robotics domain but

are necessary for efficient software development. The integration of these class

libraries also depicts software reuse, which is one of the goals of this research.

Other Components DescriptionVxWorks Wrapper Classes ⇒ Software classes that encapsulate the

functionality of the operating system.⇒ Includes classes for Object Module Loading and

Unloading, Linked Lists, Memory Partitions,Message Queues, Ring Buffers, Semaphores,Shared Memory, Symbol Tables, Tasks, andWatchdog Timers

⇒ For details see WindRiver Systems, WindFoundation Classes Component ReleaseSupplement

Iostreams Library ⇒ Support for formatted I/O in C++⇒ For details see WindRiver Systems, AT&T

Language System Library Manual

Booch Components Library ⇒ Collection of domain independent datastructures and algorithms.

⇒ Data structures include graphs, queues, rings,stacks, trees, etc.

⇒ Algorithms include date/time, searching,sorting, etc.

⇒ For details see Rogue Wave Software, C++Booch Components C++ Class Library forMultithreading and Storage Management

Tools.h++ ⇒ A C++ foundation class library⇒ Single, multibyte, and wide character support⇒ Time and date handling classes⇒ Internationalization support

⇒ Multithread safe and persistent storage⇒ Generic collection classes, etc.⇒ For details see Rogue Wave Software,

Tools.h++ Foundation Class Library for C++Programming, Introduction and ReferenceManual

Table 5.13: Sub-domains and Components to Facilitate Development.



254

5.4. Summary

This chapter presented the core of this research, that is, the abstraction (or

component) development process. First, the three basic steps of object-oriented

design were discussed. These were, analysis, design, and implementation.

Further on, an analysis of the domain of advanced robotics led to the

identification of sub-domains. Additional domains were added to facilitate

software development and testing. The next step was a detailed analysis of the

sub-domains and the identification of the software components that were a part of

the domain. These components were then analyzed independently and their

functionality, attributes, and relationships defined. After completion of the

analysis of each component, the implementation level specifications were

generated in the design phase. For all major components discussed in this

chapter, an example use was provided. The reader was asked to refer to

Appendix B for details on the interface and use of each component.



255

Chapter Six

6. Demonstrations and Experiments

6.1. Introduction

The key goal of this research was to develop an operational software

architecture (OSCAR) that had the following characteristics:

• Support for advanced robotics. Advanced robotics includes:

a. Redundant robot arms

b.

Generalized kinematicsc. Criteria-based decision making

d. Generalized dynamics

e. Deflection modeling

f. Fault-tolerance

• Completely general software architecture. Should apply to any serial arm.

• Applicability to real-time control.

• Applicability to simulation.

• Exhibit reuse through extensibility.

• Support rapid-prototyping.

• Cut down control program development time by 50%.



256

Besides the key goal of developing an operational software architecture,

the other goals of this research were:

• The selection of the software development, execution, and test environments.

• The training of future users of this software architecture.

• Extending Hooper’s [1994] generalized inverse kinematics scheme to achieve

a practical implementation.

The purpose of this chapter is to demonstrate the achievement of the goals

of this research. This is made possible by developing software applications using

the developed architecture that demonstrate each achieved goal. Additionally,

experiments were performed using this architecture to validate its advantages and

to train future users.

6.2. Applications

The following sections discuss a set of application programs that were

developed and to demonstrate the OSCAR software architecture. At the end of

each section, the characteristics of OSCAR that have been demonstrated by the

application program are listed.

6.2.1. Six Degrees-of-Freedom Inverse

This application program was developed to demonstrate the generalized

kinematics that is built into the OSCAR architecture. The RRIKJForSix class is

used for computing the generalized inverse of a six DOF robot. Additionally, an

RRFKPosition object is used to compute the end-effector position and orientation.

The application developed is completely generalized as the only inputs it takes are

the DH parameters of the robot and the starting joint position. This program is

demonstrated for a six DOF modular robot that is currently under development at

the Robotics Research Group [Grupinski, 1996]. The DH parameters (by Rich

Hooper) of this robot (used as input to this application) are listed in Table 6.1.



257

Table 6.2 outlines the key software and execution characteristics of this

application program. This program was executed on the Motorola 68030 micro-

processor running VxWorks as the operating system and the SUN SPARC 20-61

workstation running the Solaris operating system.

α i−1

(degrees) ai-1

(inches) d i(inches)

i

0.0 0.0 17.0 variable

-90.0 0.0 0.0 variable

0.0 30.0 0.0 variable

-90.0 0.0 30.0 variable

90.0 0.0 0.0 variable

-90.0 0.0 0.0 variable

Table 6.1: Denavit-Hartenberg Parameters of the Robotics Research

Modular Robot.

Key classes used RRIKJForSix, RRFKPosition

Generalized inverse scheme Resolved rate motion control

Degrees-of-freedom 6

Execution Hardware SUN SPARC 20-61, SolarisMotorola 68030, VxWorks

Control environment Simulation

Program input DH parametersInitial joint configuration

Hand position and orientationProgram output Joint angle solution

Step size 0.087 inches

Maximum error = translationalerror + 1000 * rotational error

0.00001

Solution rate 1340 Hertz (SUN SPARC 20-61,Solaris)42 Hertz (Motorola 68030, VxWorks)

Table 6.2: Characteristics of the Six DOF Inverse Application



259

6.2.2. Redundant Robot Inverse

The purpose of developing this application program was to demonstrateOSCAR’s support for computing the generalized inverse kinematics solution for

redundant robot arms. The RRIKJForGTSix class is used for computing the

inverse. The inputs into this program are the DH parameters of the redundant

robot and a starting joint configuration. This program is demonstrated on a ten

DOF robot whose DH parameters (by Rich Hooper) are listed in Table 6.3.

Table 6.4 outlines the key characteristics of this application program.

α i−1 (degrees) ai-1 (millimeters) d i (millimeters) i

0.0 0.0 0.0 variable

90.0 0.0 0.0 variable

-90.0 0.0 393.7 variable

90.0 0.0 0.0 variable

-90.0 0.0 354.330 variable

90.0 0.0 0.0 variable

-90 0.0 126.77 variable

90 0.0 0.0 variable

-90 0.0 0.0 variable

-90 0.0 0.0 variable

Table 6.3: Denavit-Hartenberg Parameters of the Ten DOF

Fault-Tolerant Arm.



260

Figure 6.2 shows the simulated robot tracing a circular end-effector path.

Some of the goals of this research that were demonstrated by this program are as

follows:

Generality: This program takes as input the DH parameters of any redundant

robot. This clearly depicts the generalized nature of the inverse kinematics

components that are a part of OSCAR.

Simulation support : The output of this application program is channeled to a

graphical simulation environment. The graphic for this application is shown in

Figure 6.2. Further, the modular robot modeling environment ROBOCAD

[Hooper, 1990] is used for the simulation. This depicts the integration of OSCAR

with an existing software base.

Key classes used RRIKJForGTSix, RRFKPosition

Generalized inverse scheme Resolved rate motion control usingPseudo Inverse


Execution Hardware SUN SPARC 20-61

Control environment Simulation

Program input DH parametersInitial joint configurationHand position and orientation

Program output Joint angle solution

Step size 2.62 mm.


0.01

Solution rate 852 Hertz

Table 6.4: Characteristics of the Ten DOF Inverse Application



261

Figure 6.2: The Ten DOF Robot Tracing a Circular Path.

6.2.3. Self Motion

This application program was developed to depict the use of the OSCAR

architecture to generate self-motions of a redundant robot arm. RRIKJPartial was

the key class used for this application. This class supports the computation of the

inverse position solution of a redundant robot arm by restricting it to a six DOF

robot. The remaining redundant joints of the robot can be locked to any desired

joint angles. Self-motion is achieved by entering the same end-effector location

while changing the joint position of the locked joint. The inputs to this program

are the DH parameters of the redundant robot and a starting joint configuration.



262

This program is demonstrated in real-time on a seven DOF Robotics Research

KB1207 arm whose DH parameters (by Rich Hooper) are listed in Table 6.5. The

KB1207 arm is a part of the Robotics Research Corporation Dual-Arm robot that

consists of a three DOF torso and two seven DOF KB1207 arms mounted on the

torso. This application used the KB1207 arm mounted on the right side of the

torso.


Figure 6.3 shows the KB1207 arm going through a set of self-motions.

Some of the achieved goals of this research that were demonstrated by this

program are as follows:

Generality: This program takes as input the DH parameters of any redundant

robot. This clearly depicts the generalized nature of the inverse kinematics

components that are a part of OSCAR.

Real-time control: The output of this application program is channeled to aphysical robot via a real-time control layer. This depicts the applicability of

OSCAR to a real-time environment.

α i−1 (degrees) ai-1 (inches) d i (inches) i (degrees)


90.0 -4.25 0.0 variable + 90.0-90.0 4.25 21.5 variable

90.0 -3.125 0.0 variable

-90.0 3.125 21.5 variable

90.0 -1.937 0.0 variable

-90.0 1.937 12.0 variable

Table 6.5: Denavit-Hartenberg Parameters of the KB1207 Seven DOF

Robotics Research Arm.



263

Key class used RRIKJPartial

Generalized inverse scheme Resolved rate motion control using a fullrank sub-matrix of Jacobian matrix


Execution Hardware Motorola 68030, VxWorks

Control environment KB1207 Robotics Research Arm

Program input DH parametersInitial joint configurationPosition of the locked jointHand position and orientation


Step size 0.01 radians


0.001


Table 6.6: Characteristics of the Self Motion Application



264

6.2.4. Real-Time Generalized Ten Degrees-of-Freedom Inverse

This application program demonstrates the use of OSCAR architecture for

real-time interactive control of a ten DOF robot in Cartesian space. The robot

used for this purpose is a composite of the three DOF torso of the Robotics

Research dual arm and the left KB1207 arm of the dual-arm. The DH parameters

for this serial arm are listed in Table 6.7 (DH parameters by Rich Hooper). This

robot is interactively controlled by the TeachBall manual controller. The OSCAR

class RRIKJForGTSix is used for computing the inverse of this robot.

End-effector remains

Stationary

Self-Motion

Figure 6.3: Robotics Research KB1207 Going Through Self Motion.



265


Figure 6.4 shows the ten DOF chain of the dual arm tracking a straight line.

α i−1

(degrees) ai-1

(inches) d i(inches)

i(degrees)


90.0 0.0 0.0 variable - 30.0

-90.0 -5.625 21.37 variable - 57.5

0.0 10.5 10.066 variable + 147.5

90.0 -4.25 0.0 variable + 90.0

-90.0 4.25 21.5 variable

90 -3.125 0.0 variable

-90 3.125 21.5 variable

90 -1.9370.0 0.0 variable

-90 1.937 15.5 variable

Table 6.7: Denavit-Hartenberg Parameters of the Ten DOF Robotics

Research Arm.



266

Some of the goals of this research that were demonstrated by this program

are as follows:

Generality: The RRIKJForGTSix class that was used for the application

discussed in Section 6.2.2 is used for this application. This clearly depicts the

generalized nature of the inverse kinematics components that are a part of

OSCAR.

Real-time control: The inverse kinematics is computed online in real-time and

the output is channeled to a physical robot via a real-time control layer. This

clearly depicts the applicability of OSCAR to a real-time environment.

Manual Controller Integration: The TeachBall was used as the input device to

control the position and orientation of the end-effector of the robot. The

RRTeachBall component was used for interfacing to the TeachBall.


Generalized inverse scheme Resolved rate motion control using pseudoinverse


Execution Hardware Motorola 68030, VxWorks

Control environment Robotics Research Dual Arm





0.001


Table 6.8: Characteristics of the Ten DOF Real-Time Interactive Inverse

Application



267

Figure 6.4: Ten DOF Robot Tracking a Straight Line.

6.2.5. Weighted Pseudo Inverse for Avoiding Joint Limits

This application was developed to demonstrate the extensibility of the

OSCAR software architecture. The generalized inverse kinematics components

for redundant arms that are supported by OSCAR rely on the pseudo inverse and

resolved rate motion control. The goal of this application was to develop a new

inverse kinematics scheme that supported a criteria-based inverse. The criterion

used for this application was the Joint Range Availability (JRA). This criterion

tends to find joint position solutions that maximize the distance of the joints from

their limits. The development of this scheme was possible through inheritance,

that is, an effort aimed at modifying relevant functionality of OSCAR while using



268

the remaining functionality. The following steps were followed to develop this

application:

• First the class that came the closest to the goals of this application was

selected. It was seen the RRIKJForGTSix class implemented a generalized

inverse kinematics scheme for redundant robots.

• The virtual method interface of this class was then studied. Essentially, the

virtual methods of a class are the ones that can be redefined in derived classes.

The three virtual methods of this class and their functionality is listed in Table

6.9.

Virtual Method Functionality

converge This method performs the numericaliterations till a joint solution is foundwithin error bounds or a singularityresults. Internally, this method callsthe other two virtual methods listed inthis table.

calculateErrorMagnitude This method computes the error in the

desired hand position and the currenthand position.

calculateDifferentialJointVector This method maps the error in thedesired hand position to an error in joint-space. The formulation usedhere is:

dq = J (J J ) dxt t 1−

,

where dq is the error in joint-spaceand dx is error in Cartesian space, andJ is the Jacobian matrix.

Table 6.9: Virtual Methods of the RRIKJForGTSix class.



269

• Once the virtual methods of the RRIKJForGTSix class are identified, the next

step is to decide which of these methods need redefinition. For this, the first

thing to study is how to compute a weighted pseudo inverse that will

minimize the distance from joint limits. For this, a weight matrix was

formulated whose diagonal elements signify the distance of a joint from its

limit. These weights are computed as:

( )wi i

icurr

il ir

ir il,

.= −−

+

−102

2

θ θ θ

θ θ ,

where( )

wi i,

is the diagonal element of the ith row and ith column of the

weight matrix W. icurr is the current position of the ith joint. θ il and ir are

respectively the left-most and the right-most joint limits of the ith joint. From

the formulation shown above, it is clear that the weight associated with a

particular joint decreases as the joint moves closer to its limits. This property

of the weighting matrix W can be used to compute the differential joint vector

dq using a weighted pseudo inverse, with W as the weight matrix. This isdone as shown:

dq WJ (JWJ ) dxt t 1= − .

The formulation shown above depicts a scheme for computing the differential

joint vector dq based on a given error hand vector dx such that the distance of

joints from their limits is maximized. For implementing this scheme, a new

class called RRIKJAvoidLimits is created. This class is derived from

RRIKJForGTSix (whose virtual methods were listed in Table 6.9). ThecalculateDifferentialJointVector method is redefined in this class. The rest of

the functionality is inherited from RRIKJForGTSix.



270

Figure 6.5 shows a plot of the distance from joint median as it varies along

the trajectory. The dashed line shows the distance from the joint median for the

pseudo inverse solution defined in RRIKJForSix and the solid line indicates the

distance from the joint median for the weighted pseudo inverse defined in

RRIKJAvoidLimits.

2.624

2.628

2.632

2.636

1 3 5 7 9 11 3 5 17 19 21 23 25 27 29

Trajectory

D i s t a n c e F

r o m M e d i a n

Minimum

Norm

Weighted

Pseudo

Inverse

Figure 6.5: Distance from Joint Median.

It is clear from the plots that the distance from the joint median decreases

for the weighted pseudo inverse scheme as the inverse progresses along the

trajectory. This difference between the dashed and the solid lines continues to

increase as the inverse progresses. This is because the weighted pseudo inverse

offers a local minimum. Thus, as the inverse progresses, small local

improvements in the solution are made over the previous solution.

Table 6.10 shows the key software and execution characteristics of this

application. This application was developed using the simulation environment

offered by Solaris. Once the application was tested on a graphical robot, the new

class (RRIKJAvoidLimits) was made available for general purpose real-time use.



271

The key goal that was demonstrated by this application is:

Extensibility: The key purpose of this application was to demonstrate the

extensibility that is built into the OSCAR architecture. It was seen in thisapplication that the developer could replace relevant parts of existing software

classes with other desired functionality. The remaining functionality of the

software class is reused in the new class that is designed by the developer. This

ability of the software supports rapid-prototyping.

6.2.6. Criteria-based Generalized Inverse

The main purpose of this application was to develop a criteria-based

generalized inverse kinematics scheme using the existing software components

provided by OSCAR. The scheme to be implemented uses the hybrid formulation

that is described in Chapter Three. This scheme basically has two steps. The first

step is the generation of a set of joint-space options that satisfy a desired end-


New class(es) developed RRIKJAvoidLimits

Generalized inverse scheme Resolved rate motion control usingweighted pseudo inverse


Execution Hardware SUN SPARC 20-61 (Solaris)

Control environment Robotics Research Dual Arm



Step size 0.1 inchesMaximum error = translationalerror + 1000 * rotational error

0.001


Table 6.10: Characteristics of the Weighted Pseudo Inverse Application.



272

effector constraint. The next step is the ranking of these options based on a set of

performance criteria. This algorithm was implemented using the RRIKJPartial

class, the RRPerformancCriteria classes, and the RRPCFusion class. The

RRIKJPartial class was used to generate a set of joint-space options. The

RRPerformanceCriteria classes were used to create three independent criteria for

this application. These three criteria were then supplied to the RRPCFusion class

for criteria fusion. The RRPCFusion was then supplied the joint-space options

that were generated by the RRIKJPartial class. These options were then ranked

by the RRPCFusion class.

This particular application was developed for a seven DOF robot arm. A

real-time implementation of this scheme was tested on the left arm of the

Robotics Research Dual-Arm robot. For comparison purposes this application

supported both the criteria-based inverse and the resolved rate motion control

scheme using the pseudo-inverse. The right arm of the dual-arm was used for the

pseudo inverse. The user of this application could interactively control both the

arms in end-effector space using the TeachBall manual controller. Additionally,

this application also demonstrated the simultaneous use of a simulation and real-time environment. This means that when the physical robot was commanded, the

graphical simulation of the dual-arm also imitated the movement of the physical

robot. The key operational characteristics of this application are listed in Table

6.11. For greater details about these application see Section 3.5.



273

This application demonstrated the achievement of the following goals: Algorithm development : This application led to the development of a criteria-

based generalized inverse scheme. The algorithm for this scheme was developed

using the framework provided by the OSCAR architecture.

Simultaneous real-time control and simulation: Simultaneous real-time control

and control of the simulation was effectively demonstrated in this application.

The control of the physical robot and the simulation occurred in parallel in this

application. The execution computer (Motorola 68030, VxWorks) communicated

with the physical robot using the VME-to-Multibus adapter and communicated

with the Silicon Graphics (simulation) using client-server classes that were

supported in OSCAR.

Key classes used RRIKJPartial, RRPerformanceCritreriaRRCriteriaFusion, RRTeachBall

Generalized inverse scheme Hybrid inverse scheme using resolved ratemotion control and direct-search


Execution Hardware Motorola 68030, VxWorks (real-time)SUN SPARC 20-61 (simulation)

Control environment Left Arm of the Dual Arm

Program input DH parametersInitial joint configurationPerformance criterion

Hand position and orientationProgram output Joint angle solution



0.01

Solution rate 30 Hertz (VxWorks, real-time)282 Hertz (Solaris, simulation)

Table 6.11: Characteristics of the Criteria-based Inverse Application



274

Performance criteria and criteria fusion: Multiple performance criteria and

criteria fusion were used in this application. The performance criteria domain is a

sub-domain of the OSCAR architecture.

Manual controller integration: The TeachBall manual controller was used in this

application to control the arms of the dual-arm in hand space. Again OSCAR’s

support for manual controller integration was used for interfacing the TeachBall

to this application.

6.2.7. Dual Arm Demonstration

This application was a major effort in developing control software for

dual-arm manipulators. This work was done as a part of a Masters thesis

[Rackers, 1996] and it involved the development of a software architecture for

coordinated control of dual-arm robots that are engaged in cooperative tasks.

Using this control scheme, the dual-arm could use both arms to hold a workpiece

and to coordinate the loads imparted on the workpiece to achieve desired task

objectives. One of the applications developed as a part of the thesis by Rackers

[1996] involved using both arms of the Robotics Research Dual Arm robot to

hold and move a flexible workpiece while maintaining constant loading on the

workpiece. A hybrid force control scheme was used for this purpose (see Rackers

[1996] for more details). Figure 6.6 shows the dual-arm robot holding a flexible

piece and moving it in a circular trajectory. Using force control, constant loads

are maintained in the workpiece.



275

Figure 6.6: Workpiece Following a Circular Trajectory.

The software for this application was developed using the OSCAR

architecture. This application relied on the generality and extensibility of the

OSCAR architecture for developing this application. New classes were created in

this application for interfacing with the robotic hardware and peripheral devices.Additionally, operational software classes were created by applying aggregation

and extensibility to the OSCAR classes (see Rackers [1996] for more details).

6.2.8. TOS Force Reflecting Demonstration

The purpose of this demonstration was to illustrate OSCAR’s support for

manual controller integration and its device independence. For this purpose the

TOS force reflecting manual controller was used. This manual controller is

interfaced to a PC running Windows NT using the NI-DAQ hardware and

software [National Instruments, 1996]. This software was developed by Peterson

[1996]. This PC also supports the OSCAR software architecture. The PC is

connected to the VME-based real-time execution hardware using Ethernet and



276

client-server software that is provided in OSCAR. The PC to which the manual

controller is connected acts as the client and the real-time computer that controls

the robot acts as the server. The client sends incremental hand position and

orientation commands to the server. The server translates these increments into

absolute position and orientation commands for the robot being controlled. As a

reply to the client, the server sends back the forces and torques that the robot is

feeling at its wrist. The client receives these forces and torques and maps them to

the joint torques of the manual controller. This process is illustrated in Figure

6.7.

Read Joint Position of TOS

Compute the position andorientation of the hand of TOS

Compute the change inhand pose from theprevious hand pose

Transmit the computeddelta hand position to theserver

Read the Force Torquesensor on robot’s wristand transmit the loads tothe client

Compute the inverseposition solution andoutput position to robot

Compute the current stateof the pose of the robotbeing controlled

Read the delta handposition sent from theclient

Receive forces andtorques from the serever

Compute the Jacobianmatrix for the currentposition of the TOS

Map the received forcesand torques to jointtorques of the TOS

Command the torques of the TOS to the computedtorques

Client: PC Server: VME Client: PC

Figure 6.7: Program Flow for the Manual Controller Demonstration.

The hardware configuration for this demonstration consists of the VME-

based real-time execution computer, the PC for manual controller integration, the

Robotics Research Dual Arm as the controlled robot, and the TOS manual

controller. This setup is illustrated in Figure 6.8.



277

The key operational characteristics of this application are listed in Table

6.12. The communication rate listed in Table 6.12 is the average data transfer

rate that was achieved between the Windows NT PC and the VME-based

execution environment.

Windows NT PC

(Client)

VME VxWorks

(Server)

Ethernet

Analog I/O

Bus-to-Bus Communication

TOS Manual

Controller

Robotics ResearchDual Arm Robot

Figure 6.8: Hardware Setup for Manual Controller Demonstration.



278

Besides demonstrating the generality and real-time ability of OSCAR, this

application demonstrated the achievement of the following goals:

Manual controller integration: The TOS manual controller was used in this

application to control the KB1207 arm in real-time. Additionally, force reflection

was also achieved in this application. Similarly, the NASA Perforce manual

controller was used to control the KB1207 robot arm.

Distributed control: The TOS manual controller and the Robotics Research Dual

arm did not share the same computer as their controlling environment. The real-

time controllers for the manual controller and the dual arm were distinct and were

loosely coupled using client/server software. This allowed for distributed control

and for modular application development.

6.3. Experiments

Key classes used RRIKJForGTSix, RRFKJacobianRRTCPClient, RRTCPServer

Generalized inverse scheme Resolved rate motion control

Execution Hardware Motorola 68030, VxWorks (server)Dell PC, Windows NT (client)

Controlled environment Left Arm of the Dual Arm (KB 1207)

Controlling environment TOS Manual Controller

Program input DH parameters of KB1207Initial joint configuration of KB1207DH parameters of TOS manual controller

Program output Joint angle solution to KB 1207

Joint Torques to TOS manual controllerClient-Server communicationrate

400 Hertz maximum set-point rate betweenthe manual controller and robot controllerusing 10 Base-T Ethernet.

Table 6.10: Characteristics of the Manual Controller Integration.



279

The goal of this research was to develop an operational software

architecture for advanced robotics. The purpose of conducting experiments with

OSCAR was two-fold:

• First, it was desired to validate and gauge the advantages OSCAR offered

over previous attempts at operational software development.

• Secondly, it was desired to train future users of OSCAR and to get feedback

regarding possible improvements to OSCAR. The next section discusses the

plan developed to achieve the experiment’s goals.

6.3.1. Experiment Plan

Before the experiments were conducted, a plan was formulated for

experiment design, evaluation of OSCAR, and the evaluation of each

experimenter. The experiment design involved the development of ten

experiments that would cover all aspects of OSCAR. The experiment evaluation

involved the comparison of OSCAR to an existing robotic software system based

on five different criteria. This evaluation was done by each experimenter after

completing an experiment. Experimenter evaluation involved determining the

weight of an experimenter. Factors such as motivation, experience, aptitude, etc.

were used to compute the effectiveness (that is, his/her associated weight in the

overall experiment) of an experimenter. The following sub-sections explain the

three stages of the experiment plan.

6.3.1.1. Experiment Design

A set of experiments was devised. These experiments involved the

development of specific applications using the OSCAR architecture. The

experiment contents and objectives were devised to expose the experimenter to all

possible aspects of OSCAR. This way, the complete architecture could be

analyzed and tested while the experimenter gained maximum exposure. Also, the



280

experiments were devised in increasing order of complexity. The first experiment

started with a simple application of software classes in the mathematical domain.

The last experiment involved developing an application in the area of interest of

the experimenter. All aspects of the OSCAR architecture were covered in these

experiments. This included the simple use of the classes provided in OSCAR,

creation of new classes using containment, and creation of new classes by

extending the existing classes. Additionally, the experiments also exposed the

users to all aspects of the development environment. This included the real-time

execution environment and the simulation environment.

6.3.1.2. Experiment Evaluation

The second step in the experimental process was gathering experimental

data. For each experiment, the experimenters filled out an evaluation sheet in

which they compared certain aspects of OSCAR with a software environment that

they had used in the past. This data after being normalized based on experimenter

qualification would supply the results of the experiments. The following criteria

were used to compare OSCAR to other software systems that the experimenter

had used in the past.

• Ease of Use.

• Organization.

• Generality.

• Time to code.

• Time to test.

The ‘Ease of Use’ and ‘Organization’ criteria basically provide a measure

of the structure and layout of the software. The ‘Generality’ criterion provides a

measure of the applicability of the software component to different applications

and robots. The ‘Time to Code’ and ‘Time to Test’ criteria provide a measure of



281

the productivity enhancements that the OSCAR architecture provides over the

system it was being compared with.

6.3.1.3. Experimenter Evaluation

The third step in the experimental process was analyzing experimenter

qualifications. The qualifications of an ideal experimenter were:

• Experienced with object-oriented programming using C++.

• An understanding of the domain of advanced robotics.

• Previous experience with robotics software in a structured or object-oriented

environment other than OSCAR.

It was realized that none of the experimenters would completely match the

ideal qualifications. This was because the experimenters came from varied

backgrounds. For example, some experimenters had programming experience

with mathematical software like Matlab and Mathematica, but lacked in the area

of structured or object-oriented programming. Other experimenters were

experienced with structured programming but lacked knowledge of the domain

(advanced robotics). And, some were experienced in the domain of advancedrobotics and C++ programming, but had never used any robotics software

development environment with which they could make valid comparisons. Thus,

the comparative data gathered in the second step had to be normalized based on

user qualification as compared to the ideal qualification. Hence, a survey was

developed which was used to ascertain an experimenter’s qualification. This

survey gauged the experience of an experimenter in four areas. These were:

• Experience in C and C++ programming. Greater experience with C and C++

improved the effectiveness of the experimenter.

• Knowledge of the advanced robotics domain. Greater understanding of this

domain improved the effectiveness of the experimenter.



282

• Experience with the software system the experimenter is comparing to

OSCAR. The experience with this software system should be at the same

level as the previous experience with programming in C/C++ type structured

or object-oriented environments. This is necessary for unbiased results. A

greater difference between an experimenter’s experience with C/C++ type

environments and the software system with which the comparison is being

made, lowers the effectiveness of the experimenter.

• How closely does the compared software system satisfy operational software

needs of advanced robotics (that is, the main purpose of OSCAR). This

criteria again decides the effectiveness of an experimenter. If the software

system with which the comparison is being made matches the operational

requirements that OSCAR fulfills, the greater the effectiveness of the

experimenter. For example, if the experimenter is comparing OSCAR to a

software based on a symbolic manipulation language like Mathematica, the

effectiveness of the experimenter would be considerably lower. However, the

effectiveness of an experimenter would be considerably higher if the

comparison is made with a library of C functions for robot control.

Besides the data collected from this survey, a measure of aptitude of the

experimenter and their motivation had to be generated. This was done by the

people who were monitoring the progress of the experiments and were

responsible for the academic supervision of the experimenters.

Finally, based on the degree of match between the experimenter

qualification and the ideal qualification, the aptitude, and motivation, different

weights would be generated for each experimenter. An experimenter with a

higher weight would have a greater impact on the results of the experiments. An

experimenter with a lower weight would have a lesser impact. After a weighting

measure has been generated for each experimenter, this weight would be applied

to the experimental data collected in step two. After this, the normalized



283

experimental data is summed up for all experimenters. The results provide a

comparison between OSCAR and other robotic software environments.

The previous paragraphs discussed the plan that was to be followed for

successfully conducting experiments with OSCAR and generating some results.

To summarize, the key steps in the plan were:

• Devise a set of software experiments that were to be conducted by the

experimenters.

• Develop a set of criteria that would be used to make comparisons between

OSCAR and another software environment the experimenter is familiar with.

• Collect data regarding an experimenter’s experience, aptitude, and motivation.

Using this data, generate a weight for each experimenter.

• Normalize experimenter data based on their weight.

• Combine all normalized experimental data to come up with overall results.

6.3.2. Experimental Activity

The experimental activity began by the selection of a group of

experimenters. These experimenters were selected based on the followingfactors:

• The selected candidate’s academic research should be related to the OSCAR

software architecture.

• A selected candidate would in all probability be a future user of OSCAR.

• The selected candidate’s qualifications should closely match the qualifications

of the ideal experimenter.

Considering the factors mentioned above, eight candidates were selected. All

these candidates are members (students and staff) of the University of Texas,

Robotics Research Group. Six of these eight candidates (called candidates A

through F) were divided into three teams of two each. The teams were selected in

a manner such that one team member had a stronger programming background



284

and the other had a stronger robotics background. The other two candidates (let

them be known as G and H) were experienced programmers and roboticists. Both

of these candidates had extensive programming and robotic software experience.

This made these candidates ideal for making relevant comparisons of OSCAR

with the software system they had used in the past.

Ten experiments were devised for the candidates A through F and H.

These experiments are listed in Appendix C. Each experimenter was given a

week each to finish an experiment. This included coding and testing. The

experiments were started on April 1,1996 and they ended June 30, 1996. The

extra duration was used to compensate for the experimenters other engagements

(exams, etc.). For each experiment performed, an experimenter filled out an

evaluation sheet. Comparison were made between OSCAR and another software

environment that the experimenter had used in the past for robotic software

development. This evaluation sheet is shown in Table 6.13. The experimenters

were asked to compare the features listed in Table 6.13 on a scale of 1 through 10,

where 1 implied a poor ranking and 10 implied very good.

The candidate G was also asked to fill out the evaluation sheet for the

software development being done as a part of his/her research work. Each

experimenter filled out the evaluation sheet for every assignment they undertook.

Environment

Criteria

OSCAR Software Libraries the User

has used in the Past

Ease of Use

Generality

Organization

Time to Code

Time to Test

Table 6.13: Evaluation Sheet for Experiments with OSCAR.



285

The results of each evaluation were then summed up and averaged for each

experimenter.

Besides filling out the evaluation sheet shown in Table 6.13, each

experimenter was asked to fill out a survey that was designed to gauge their

experience and qualifications. The data collected from this survey would be used

to weight each experimenter. The closer an experimenter came to the ideal

experimenter, the higher would be their weight. The survey filled out by the

experimenters is shown below:

• On a scale of 1 to 10, how would you gauge your experience with the

software system you are comparing OSCAR with, to programming in a

C/C++ type environment (use experience level before the beginning of the

experiments)?

C/C++ Type ___________ Compared Software System _______ _____

• What is the primary software system you were comparing OSCAR with (give

details)?

______________________________________________________________

______________________________________________________________

______________________________________________________________

______________________________________________________________

______________________________________________________________

The survey shown above tries to derive a measure of the experimenter’s

experience with C/C++ type programming environment as compared to the

software environment they are comparing OSCAR with. An experimenter who

has equivalent experience in both the environments is a better candidate than

someone who has dissimilar experience in the two environments. Additionally,

an experimenter is asked to describe the environment they are comparing OSCAR

with. Again, the weight carried by an experimenter is dependent on the

environment they are comparing OSCAR with. The assessment of how closely



286

the compared environment matched the goals of OSCAR was made subjectively

by the present researcher and the Chief Scientist of the Robotics Research Group.

Additionally, a measure of the experimenter’s understanding of the robotic

domain and previous experience with robotics software was assessed by the

Director of the Robotics Research Group (also academic advisor).

Besides information gathered from the experimenter survey, additional

information was used to gauge the weight of an experimenter. This information

regarding the motivation and aptitude of an experimenter. The motivation of all

the experimenters was ranked between 1 and 10 by the author and the Chief

Scientist of the Robotics Research Group. A higher number indicated a greater

motivation and thus increased the weight of an experimenter. The aptitude of an

experimenter was judged by the author and the Director of the Robotics Research

Group (and academic supervisor of the experimenters). A higher aptitude

suggested a “fast learner” and thus increased the weight of the experimenter. The

overall weight of an experimenter was determined using the following

formulation:

W E E C A M r co o= * * * * , where

W = the weight of the experimenter,

E r = the robotic software and domain experience of an experimenter

(scale 1 to 10),

E

E

E if E E

E

E if E E

co

c

o

c o

o

c

o c

=≤

<

, where

E c = the experience with a C/C++ type environment (scale 1 to 10),

E o = the experience with the other environment with which OSCAR is being

compared (scale 1 to 10),



287

C o = a measure of how closely the compared software environment fulfills the

goals that OSCAR is supposed to fulfill (scale 1 to 10), A is an aptitude measure of the experimenter (scale 1 to 10), and

M is a measure of motivation of the experimenter (scale 1 to 10).

This section explained the process of conducting the experiments,

gathering data, and the formulation used to normalize the data. The next section

discusses the results of these experiments.

6.3.3. Experiment Results

The evaluation data for each experiment conducted by the experimenters

is listed in Appendix C. Also, listed are the comments of the experimenters

regarding improvements to OSCAR and the bugs they encountered during the

experiments. Along with this data are listed the experimenter questionnaire that

tries to compare the experimenter’s experience with C/C++ type environments

and the environment he/she is using for comparison.

The first step in analyzing the data listed in Appendix C was to isolate the

experimental data for each experimenter. This data was then summed up for eachexperiment that an experimenter had performed. After this the data was

normalized over a scale of 1 to 10.

6.3.3.1. Individual Experimenter Results

Figure 6.9 shows plots of the evaluation data produced by Experimenter

A. Eight experiments were conducted and the software compared to OSCAR was

Matlab. The plots show that the time to code for OSCAR is considerably less.

One possible reason for this is that Matlab does not directly support robotic

software development, which is the primary goal of OSCAR. As this

experimenter is comparing OSCAR to Matlab, his/her weight will be



288

considerably lowered (see Table 6.14). This is because Matlab does not satisfy

operational requirements for robotic software.

Figure 6.10 shows the plots of the evaluation data produced by

Experimenter B. Nine experiments were conducted by this experimenter. Of

these, the last experiment was self-defined in the area of interest of the

experimenter. The OSCAR environment was compared to the symbolic

manipulation software Mathematica. From the plots it is seen that the time to

code for OSCAR is considerably less. One reason given by the experimenter for

this was the inefficient programming environment offered by Mathematica. Also,

Mathematica does not directly support robotic software development.

Ease of Use Generality Organization 1/Code Time 1/TestTime

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

Ease of Use Generality Organization 1/Code Time 1/TestTime

OSCAR

Matlab

Figure 6.9: Averaged Evaluation Data for Experimenter A.



289

The graph in Figure 6.11 illustrates the comparisons made by

Experimenter C. OSCAR in this case is compared to Matlab.

Ease of Use Generality Organization 1/Code Time 1/Test Time

0

1

2

3

4

5

6

7

8

9

10


OSCAR

Mathematica

Figure 6.10: Averaged Evaluation Data for Experimenter B.

Ease of Use Generality Organization 1/Code Time 1/ Test Time

0

1

2

3

4

5

6

7

8

9

10

Ease of Use Generality Organization 1/Code Time 1/ Test Time

OSCAR

Matlab

Figure 6.11: Averaged Evaluation Data for Experimenter C.



290

Figure 6.12 illustrates the average evaluation data produced by

Experimenter D who conducted six experiments. The OSCAR environment was

compare to REDUCE, which is a symbolic manipulation language for

mathematical computations. Again, OSCAR is more than twice as good as

REDUCE when comparing coding and testing time. One reason for this is that

OSCAR directly supports robotics while REDUCE just supports mathematical

computations.

Experimenter E compared OSCAR to programming in Matlab and C++.

For the first two experiments, comparison was made with Matlab. For the

remaining seven experiments, the comparison was made with the experimenter’s

personally developed C++ code. The averaged evaluation data produced by

Experimenter E is shown in Figure 6.13.

Ease of Use Generality Organization 1/Code Time 1/Test ime

0

1

2

3

4

5

6

7

8

9

10

Ease of Use Generality Organization 1/Code Time 1/Test ime

OSCAR

REDUCE

Figure 6.12: Averaged Evaluation Data for Experimenter D.



291

Experimenter F conducted eight experiments and compared OSCAR to

the Matlab programming environment. The evaluation data produced by this

experimenter is shown in Figure 6.14.


0

1

2

3

4

5

6

7

8

9

10


OSCAR

Matlab and C++ Code

Figure 6.13: Averaged Evaluation Data for Experimenter E.


0

1

2

3

4

5

6

7

8

9

10


OSCAR

Matlab

Figure 6.14: Averaged Evaluation Data for Experimenter F.



292

Experimenter G was an experienced C++ programmer and was well

versed in the domain of advanced robotics. This experimenter did not conduct the

experiments listed in Appendix C. However, software for the experimenter’s

Masters thesis research was developed using OSCAR. Previously, this

experimenter had robotics programming experience using the C library functions

provided in Numerical Recipes in C [Press et al., 1991]. These library functions

have been used at the Robotics Research Group to develop robotic software. The

evaluation data produced by this experimenter is shown in Figure 6.15. It is clear

form this data that OSCAR shows improvements in all areas it was evaluated in.

More than a two-times improvement is shown by OSCAR in coding and testing

time. The primary reasons for this is OSCAR’s direct support for advanced

robotics, the organization, and the object-oriented nature of the software

components supported by OSCAR.

Experimenter H is the most experienced in the software systems that are

used at the Robotics Research Group and has the best understanding of the


0

1

2

3

4

5

6

7

8

9

10


OSCAR

C Libraries

Figure 6.15: Evaluation Data for Experimenter G.



293

domain. Additionally, Experimenter H is a key robotic software developer at the

Robotics Research Group and is also a user of other commercially and

academically available robotic software systems. From the experimenter

evaluation, it was found that this experimenter had a greater experience level in

using C library type environments as compared to C/C++ type object-oriented

environments. This lowered the weight of the experimenter. Additionally, the

software with which OSCAR was being compared was developed by the

experimenter. This also, would bias the results against OSCAR. However, the

evaluation data produced by experimenter H still showed the superiority of

OSCAR over the previously used robotic software system at the Robotics

Research Group (see Figure 6.16). This experimenter conducted seven of the

experiments that are listed in Appendix C. The averaged comparison data is

depicted in Figure 6.16.

As mentioned earlier, Experimenter H was comparing OSCAR to a library

of C functions that were primarily developed by himself/herself. However, these


0

1

2

3

4

5

6

7

8

9

10


OSCAR

C Libraries

Figure 6.16: Evaluation Data for Experimenter H.



294

functions were not organized in a manner to promote their use by other

developers. This is evident from the quote by Experimenter H,

“It seems that using OSCAR is allowing some of our students with

limited software experience to write programs implementing very

complex geometry, mathematics, and kinematics. I don’t think they

would be able to write these programs from scratch without one or more

years of work. The comparison to the C environment we were using

previously is somewhat difficult. We are now experiencing much better

software reuse than we were before. Basically, over the previous 8 years

we had little to no software reuse. Now we are reusing software, but we

are making an effort to reuse the software. Before we had very little

reuse effort and very little reuse. Ultimately time will tell the success of

the reuse effort.”

Drawing inferences from Experimenter H’s comments, it is clear that

OSCAR is the first software environment that is being used by developers at the

Robotics Research Group. Also, significantly more effort would be necessary to

develop robotic programs without OSCAR. However, from Experimenter H’scomparison data (see Figure 6.16) it is clear that OSCAR does not show

significant improvement over robotic software that was previously used at the

Robotics Research Group. This result is understandable because the software

with which OSCAR is being compared was developed by Experimenter H. This

biases the results against OSCAR. Additionally, Experimenter H’s experience

with object-oriented systems is limited as compared to experience with structured

systems. Due to the lack of experience with object-oriented system, the reuse

potential of OSCAR was not evident to experimenter H. Experimenter G on the

other hand was experienced with structured and object-oriented systems.

Experimenter G had attempted robotic software development using the structured

environment that was previously available at the Robotics Research Group.



295

However, Experimenter G shifted to OSCAR when it was made available. For

these reasons, Experimenter G possibly was the most effective experimenter. The

effectiveness of each experimenter is discussed in the next section.

6.3.3.2. Overall Experiment Results

Once the evaluation and comparison data was gathered for all

experimenters, the next step was the normalization and averaging of this data to

reach an overall result. This process is explained in this section.

The evaluation data produced by the experimenters is graphically

illustrated in Figures 6.9 to 6.16. The final step in the evaluation of OSCAR is

the normalization and averaging of the data produced by the various

experimenters. Before normalization, individual weights of each experimenter

had to be assessed based on experimenter experience, motivation, aptitude, and

the environment they were comparing OSCAR with. Section 6.3.1 discussed the

process and the formulation used in assessing the weight of an experimenter. The

data gathered for this purpose is listed in Table 6.14. The last column

(highlighted) of this table gives the overall weight of the experimenter. The

greater the weight of an experimenter, the greater is the impact on the overall

results of the experiments.



296

Clearly, from Table 6.14, experimenter G will have the highest impact on

the outcome of the experiments and experimenter C will have the minimum

impact on the outcome. The primary reason for this is that experimenter G had

equivalent experience in structured and object-oriented systems and was

experienced in robotic software development. Also, experimenter G was

comparing OSCAR to a system that satisfied similar goals.

Analyzing the contents of Table 6.14, the experimenters can be divided

into two groups. These are experimenters that compared OSCAR to

mathematical software like Matlab and Mathematica and experimenters that

compared OSCAR to robotic software that was written in C and C++. This

included the robotic software that was previously developed at the Robotics

Research Group. As the two software types with which OSCAR is beingcompared are significantly different, it is appropriate to draw two conclusions.

These conclusions are drawn from OSCAR’s comparison to mathematical

software and from OSCAR’s comparison to previously developed robotic

Experimenter Compared

Software

E r E c E o E co C o A M W

A Matlab 3 7 5 0.71 3 3 7 135

B Mathematica 4 8 4 0.5 2 5 7 140

C Matlab 1 1 8 0.13 3 5.5 2 4

D REDUCE 4 3 4 0.75 2 8 5 240

E Matlab and personalC++ code

3 4 2 0.5 5 8.5 9 574

F Matlab 3 1 9 0.11 3 9 9 80

G Numerical Recipes inC

7 5 5 1 7 9 10 4410

H Previous roboticsoftware written in C

at the RoboticsResearch Group

9 3.5 8.5 0.412 9 9 8 2403

Table 6.14: Assessed Weight of Each Experimenter.



297

software at the Robotics Research Group. These conclusions are discussed in the

following sections.

6.3.3.2.1. OSCAR Compared to Mathematical Software

From Table 6.14 it is clear that experimenters A, B, C, D, and F compared

OSCAR to mathematical software. These were Matlab, Mathematica, and

REDUCE. All these software products are used for mathematical modeling of

systems and do not satisfy operational requirements and are unsuitable for real-

time control. Considering the weight of each experimenter in this group, the

comparison data was averaged and the results are shown in Figure 6.17.

From Figure 6.17 it is clear that OSCAR fares better than mathematical

software in all aspects. The primary reason for this is the inability of

mathematical software to support large-scale program development and their lack

of direct support for robotic software. Additionally, these mathematical software

systems would not support a majority of applications that could use OSCAR (for

example, distributed real-time control).


0

1

2

3

4

5

6

7

8

9

10


OSCAR

MathematicalSoftware

Figure 6.17: OSCAR Compared to Mathematical Software.



298

6.3.3.2.2. OSCAR Compared to Robotic Software

Table 6.14 indicates that experimenters E, G, and H compared OSCAR topreviously developed C/C++ robotic software. Most of this software was

developed at the Robotics Research Group and it satisfied similar goals as

OSCAR does. Thus, it was decided to average the evaluation data produced by

experimenters E, G, and H. The results of the average are depicted in Figure

6.18.

From Figure 6.18 it is clear that OSCAR shows improvement over C/C++

type robotic software systems that were previously being used at the Robotics

Research Group.

6.4. Summary


0

1

2

3

4

5

6

7

8

9

10


OSCAR

C/C++ RoboticSoftware Systems

Figure 6.18: OSCAR Compared to C/C++ Type Robotic Software Systems.



299

This chapter presented the validation for this research. The OSCAR

architecture was demonstrated through example applications. These applications

include the demonstration of OSCAR’s support for simulation and real-time

computing. The generalized kinematics and other domains built into OSCAR

were demonstrated. Operational characteristics of each application were also

discussed. Additionally, OSCAR’s support for manual controller integration and

distributed computing was demonstrated. The ability to develop new components

via aggregation and extension was also demonstrated.

A desired characteristic of this research was that OSCAR should reduce

robot control program development time by 50%. This hypothesis was tested by

conducting experiments with OSCAR. For this purpose eight experimenters were

chosen and a set of ten experiments designed. The experimenters completed

these experiments in four months and filled out an evaluation sheet. In this they

compared OSCAR to a software system which they had previously used for

robotic software development. Besides evaluation of OSCAR by experimenters,

an evaluation of experimenters was also performed by the author and staff at the

Robotics Research Group. Considering experimenter evaluation, weights wereassigned to each experimenter. An experimenter with a higher weight had a

greater impact on the final outcome of the experiments. The experimenters

compared OSCAR to primarily two software systems. One was mathematical

software (Matlab, Mathematica, etc.) and the other was robotic software written

in C/C++ that was previously used at the Robotics Research Group. The

averaged data for each group showed that OSCAR was more general, easy to use,

and better organized than mathematical software and C/C++ type robotic software

that was previously used at the Robotics Research Group. Also, OSCAR reduced

program development time (time to code and time to test) by a factor of three as

compared to mathematical software and C/C++ type robotic software that was

previously being used at the Robotics Research Group.



300



301

Chapter Seven

7. Summary and Proposed Future Development

A summary of the previous chapters of this report is provided in the first

section of this chapter with primary conclusions. In the second section,

applications of this research, recommendations and suggestions for future

directions of this development are discussed.

7.1. Summary and Conclusions

This section contains the summary of the report. The summary of the

objectives, the literature review, the research accomplished, and demonstrations is

provided.

The overall goal of this research has been to develop a software

architecture that supports control program development for advanced robotics.

This software architecture is called “Operational Software Components for

Advanced Robotics” (OSCAR) in this report. The research objectives for

accomplishing this goal were discussed in Chapter One and are summarized in

Table 7.1 (see Section 1.2). Chapter One also discussed the key characteristics of

an advanced robotic system. These were, modularity, generalized kinematics,

generalized dynamics, deflection modeling, fault-tolerance, and decision making

(see Sections 1.5 to 1.9). Additionally, the three layers of robotic software at the



302

system level were discussed (see Section 1.1). These were man-machine

interface, operational software, and real-time control. This research was to focus

on the middle layer (operational software layer) of the robotic software.

7.1.1. Summary and Conclusions of the Literature Review

Chapter Two presented the literature review for this research. Thisincluded a review of past and current robot technology (mechanical hardware,

computer hardware, and software). Based on the state-of-the-art in robot

technology, a set of requirements were generated. These requirements would

Research Objectives

• Develop a software architecture (OSCAR) that supports advanced

robot control program development. This architecture should:

Be completely general, that is, apply to any serial arm

Be applicable to real-time control

Be applicable to simulation

Exhibit reuse via extensibility

Support rapid-prototyping

Cut down control program development time by 50%

Select and develop the software development, execution, and test

environment.

Training of future users of OSCAR.

Develop application programs to demonstrate OSCAR.

Achieve a practical implementation of Hooper’s [1994] generalized

inverse kinematics scheme.

Table 7.1: Research Objectives.



303

guide the development of the software architecture for this research. These

requirements are condensed and listed in Table 7.2. The primary requirement that

was met was generality, extensibility, and potential for reuse.

Technology Impact on Software Requirements

Mechanical (see Section 2.2)

⇒ Reconfigurability⇒ Generality⇒ Deflection modeling⇒ Dynamic modeling⇒ Generalized kinematics⇒ Obstacle avoidance⇒ Decision making⇒ Performance criteria⇒ Criteria fusion and normalization⇒ Sensor fusion⇒ Fault-tolerance⇒ Data-base driven machines⇒ Condition-based maintenance⇒ Stringent real-time constraints

Control Hardware(see Section 2.3)

⇒ Cleaner well defined software architecture⇒ Distributed approach to software structure⇒ Multi-processing software⇒ Greater reliance on operating system software⇒ Relaxed real-time constraints

Computer Hardware(see Sections 2.3 and2.7)

⇒ Develop generalized software⇒ Greater error checking⇒ Software will result in the greatest “value added”⇒ Generalized algorithms⇒ The era of “real” intelligent machines is here

Software(see Section 2.4)

⇒ Object-oriented software architecture⇒ Standardization and modularity⇒ Software reuse via generality and extensibility⇒ Software assembled from a library of components⇒ Reduction in program development time⇒ Performance

Table 7.2: Impact of Various Technologies on Software Requirements.



304

Once the software requirements for an advanced robot were generated,

existing robotic software environments were reviewed (see Section 2.6). A brief

analysis of these environments is listed in Table 7.3. The primary environment

for this software development was taken to be object-oriented structures.



305

Research Summary

RCCL(see Section 2.6.2.1)

− Based on the C programming language− Uses UNIX for real-time control− Advanced robotics not supported− Based on structured design− Software generality and extensibility missing

RIPE(see Section 2.6.2.2)

− Primarily a robot programming environment− Uses object-oriented design to provide standard robot

programming interface− Advanced robotics not supported− Developed by Sandia National Laboratories

GISC (see Section 2.6.2.3)

− Integrates RIPE for robot programming− Works at a supervisory level to the system controller− Uses object exchange for distributed computing− Does not address operational software needs of system

controllers− Developed by Sandia National Laboratories

SMART (see Section 2.6.2.4)

− System that comes closest to satisfying the goals of thisresearch

− Addresses kinematics and dynamics− Does not seem like a completely generalized architecture− Available as set of C functions.− Limited reuse potential due to lack of object-oriented

architecture− Developed by Sandia National Laboratories

Control Shell (see Section 2.6.2.5)

− Component-based real-time programming system− Addresses all layers of robotic software− Lacks in operational software components for advanced

robotics− Would be ideal for integration with this research

Robot Shell (see Section 2.6.2.6)

− For non-real-time systems− Does not support advanced robotics− Cannot be used for large-scale systems− Basically a calculator for robotic computations

C H

Programming

Language(see Section 2.6.2.7)

− Supports Complex, Dual, and Array data types− Extensibility through inheritance and parameterized types

not supported− C++ is a better choice for developing design software

Other object-oriented

Robotic Software System(see Section 2.6.2.8)

− Object-oriented design primarily used to providestandardized interfaces and data abstraction

− Primarily robot programming and integration environments

− Research basically stresses the advantages of object-oriented design for machine control software

Table 7.3: Summary of Robotic Software Systems.



306

The literature survey indicated that a majority of the robotic software

systems focused on the hardware interfacing layer and the man-machine interface.

Minimal work had been done in developing the operational software layer for

advanced robots. The primary reason for this was that advanced robots being

complex machines, were rarely used in an application environment. Another

reason was that most of the algorithms for controlling advanced robots were

different and an order of magnitude greater in complexity as compared to

standard industrial robots. For example, the robotic software systems being

developed at Sandia National Labs (see Sections 2.6.2.2 to 2.6.2.4) were aimed at

developing a software architecture for hardware interfacing and a robot

independent programming environment. These efforts would result in the

reduction of the integration and programming time for a robot. However, these

systems were primarily used to control standard six DOF industrial robots. Issues

involved with advanced robotics were not addressed. The OSCAR architecture

when combined with the work done at Sandia National Labs could offer a

comprehensive system for advanced robot control, programming, and integration.

Chapter Two also discussed in detail the predominant software designmethodologies. These were structured design and object-oriented design (see

Section 2.5.1)). Of these, object-oriented design offered the advantages of

modularity and reusability (see Section 2.5.1.2). The literature review suggested

that there was a trend to move to object-oriented design for robotic software

development. However, this effort was lacking in the area of advanced robotics

and operational software. Reviewing the software design philosophies it was

concluded that object-oriented design would offer the best tool to achieve the

research goals.

Chapter Two also highlighted the advancement in computer technology

and the impact it would have on robotic software systems. It was seen that the

gap between personal computer computing power and the super-computer was



307

decreasing. This has resulted today in the availability of 400 MFLOP computing

power from desk-side computers (see Section 2.7). A review of robotics literature

had shown that a major research effort was spent on modifying existing

algorithms to improve their efficiency. This usually destroyed the generality of

the software. Additionally, research work had also concentrated on designing

new computer architectures and chips for robotic computations. The problem

with robotics research in the area of designing fast computer architectures and

modifying existing algorithms for computational efficiency was that, the effort

was being spent on a problem that will no longer exist in the future. This will be

due to the advancement in computer technology. An example to illustrate this

issue was presented: Wander in 1987 was able to compute robot dynamics for a

six DOF arm on a specialized and expensive array processor in five milliseconds

using a laboriously written code. The same performance is now (1996) possible

on a low-cost high-end personal computer using generic software environments.

In summary, the literature review provided an argument for developing an

operational software architecture for advanced robots. This architecture should

be completely general and should apply to real-time control and simulation.Furthermore, this architecture should reduce robot control program development

time by 50%.

7.1.2. Summary and Conclusions of the Generalized Inverse

Chapter Three discussed Hooper’s [1994] technique for criteria-based

generalized inverse kinematics (see Section 3.2 for details on inverse kinematics).

This technique relied on using the direct-search algorithm for generating a set of

joint-space options that satisfied an end-effector constraint. After these joint-

space options are generated, they were ranked based on input criteria. The option

that best satisfied the criteria was chosen as the inverse solution (see Section 3.3).

For computational efficiency, Hooper extended this technique by using a closed-



308

form inverse position solution for a six DOF sub-structure of the redundant arm.

The strengths and weaknesses of this scheme were discussed and are listed in

Table 7.4 (see Sections 3.3.1 and 3.3.2). It was another goal of the present

research to overcome some of these limitations.

As mentioned earlier, Hooper [1994] incorporated a closed-form solution

to achieve computational efficiency. This caused loss of generality and

inapplicability to level III fault-tolerance. The present research focused on

modifying this aspect of Hooper’s technique. This was done by replacing the

closed-form solution by a computationally efficient six DOF generalized inverse

solution (see Section 3.3). The resolved rate motion control scheme was used to

implement this six DOF generalized inverse. Under this new scheme (called

hybrid scheme), six joints of a redundant arm were selected for resolved rate

motion control and the remaining were used for direct-search (see Section 3.4.1).

Further, a preliminary scheme for criteria fusion was developed. This

relied on using a weighted sum of individual criterion. Under this approach,

joint-space options were first ranked for each criterion. The next step involved a

weighted sum of the rank of each joint-space option for each criterion. This

resulted in a cumulative rank for each joint-space option (see Section 3.4.2).

The following conclusions were drawn from this effort:

Hooper’s Generalized Inverse Formulation

Strengths Weaknesses

• Based on the forward position solution • Completely generalized formulationis computationally inefficient

• Incorporation of multiple criteria isdecoupled from the solution of theinverse kinematics

• Modified Hooper’s technique (byincorporating a closed-formsolution) is not general

Table 7.4: Strengths and Weaknesses of Hooper’s Formulation.



309

• A practical and generalized implementation of a multi-criteria inverse

kinematics problem was achieved. This was demonstrated in real-time on a

seven DOF robot. In this case, the application demonstrated a 170-times

performance improvement over the direct-search technique that was initially

proposed by Hooper [1994] (see Section 3.5).

• The layout of the developed scheme supports level III fault-tolerance.

• The weighted sum technique for criteria fusion can lead to ambiguities. This

happens when a two or more joint-space options have the same overall rank.

This conflict can be resolved using improved criteria normalization with

direct operator intervention.

Further work that needs to be done in developing the hybrid generalized

inverse scheme is as follows:

• The selection of the full rank sub-matrix of the Jacobian matrix for the

computation of the sub-structure inverse should be optimized. Currently, this

selection is arbitrary. A six joint sub-structure of the Jacobian could be

selected by computing the determinant of all the possible full rank Jacobian

sub-matrices. After this, the Jacobian sub-matrix that has the highest

determinant should be selected. However, the determinant is not a good

measure of the distance from a singularity. As an improvement to this, it

would be better to base the selection of the Jacobian sub-matrix by using the

condition number that is computed through Gaussian elimination. The

condition number is a better measure of the distance from singularity than the

determinant. However, the computation of the condition number or

determinant of all possible full-rank sub-matrices of the Jacobian matrix can

be computationally inefficient. Another means of finding the best sub-matrix

of the Jacobian is by conducting a Singular Value Decomposition (SVD) of

the Jacobian matrix and finding the best six constraint equations. This would



310

be a “one-shot” approach as compared to computing the determinant (or

condition number) for all possible full rank sub-matrices of the Jacobian

matrix.

• The second area that needs further work is level III fault-tolerance. The

current algorithm and its implementation support level III fault-tolerance.

However this has not been tested and debugged. Further work needs to be

done to make this operational and robust.

• The weighted sum technique for criteria fusion was seen to have limitations.

Many of these limitations can be overcome by improving the development of

criteria normalization. A weighted sum of the normalized criterion values

would result in an improved selection of the best joint-space option

7.1.3. Summary and Conclusions of the Environment Selection

The focus of Chapter Four was to discuss the process involved in the

selection of the software development, execution, and test environment. This

included computer hardware, interfacing hardware, robotic hardware, software

development tools, programming languages, design methodology,

communications hardware, and architecture and organization of the software and

the hardware.

The approach taken for environment selection involved the individual

selection of systems that made up the development, execution, and test

environment. This approach was taken even though it was known that individual

system selection was not independent of each other. However, by individually

selecting systems, a clearer picture of what was best was gained. After the

identification of the best sub-system entities, iteration was used to select entities

for all the sub-systems. A summary of the final selected environment is given in

Table 7.5.



311

In addition to the selection of the development and execution

environment, software was also developed for manual controller integration. This

was possible because the integration of manual controllers required minimal

effort. This was due to the distributed and modular architecture of OSCAR.

Secondly, the OSCAR software architecture could be tested and could be used to

evaluate and study various manual controllers. A distributed approach was taken

for manual controller integration as opposed to centralized control (see Section

4.5). Ethernet was used as the hardware medium for inter-computer

communication. The software used for the communication relied on TCP sockets

(see Section 4.5).



312

Some issues that were raised in Chapter Four are summarized below:

• Cross-development systems are harder to learn but offer a much more flexible

environment. Software tools are not as advanced for cross-development

systems (see Section 4.1).

System Selected System Reasons For SelectionSystem Type(see Section 4.1)

Cross-Development ⇒ VxWorks is a cross-developmentsystem.

⇒ Execution hardware can be changedwith minimal changes to thedevelopment environment.

Software DesignParadigm(see Section 4.2.1)

Object-Oriented Design ⇒ Modularity⇒ Extensibility⇒ Standardized interface⇒ Encapsulation⇒ Rapid-prototyping

Computer Language(see Section 4.2.2)

C++ ⇒ Supports object-oriented programming⇒ Availability⇒ Compatibility with C

Host Computer(see Section 4.2.3)

SUN SPARC 20-61(Solaris 2.2)

⇒ VxWorks development tools were bestsupported.

⇒ Best price/performance ratio of allworkstations.

Execution OperatingSystem(see Section 4.3.1)

VxWorks ⇒ Hard real-time system⇒ Best support for development tools⇒ Support for fast processors⇒ Project requirements (suggested by

Department of Energy)

Execution Processor(see Section 4.3.2.1)

PowerPC (604) ⇒ Supported by VxWorks⇒ Clearly defined future path⇒ Computational efficiency⇒ Availability on VME

Computer Bus(see Section 4.3.2.2)

VME ⇒ Abundant processor support⇒ VxWorks support⇒ Availability of bus-to-bus adapters⇒ Abundant supply of various plug-in

cards

Table 7.5: Summary of Selected Systems.



313

• The availability of PowerPC processors has not been as rapid as forecasted. A

viable alternative for the processor of the execution environment is the

Pentium family of processors from Intel (see Section 4.3.2.1).

• The suitability of Windows NT for real-time control needs to be studied.

Windows NT is a soft-real-time system. This means that Windows NT allows

for preemptive execution of parallel tasks but does not guarantee interrupt

latency bounds (approximately six microseconds for VxWorks).

• A SUN workstation was selected as the computer for the development

environment. A Windows NT-based PC could offer a cheaper and equally

powerful option at this time (July, 1996).

7.1.4. Summary and Conclusions of the Abstraction Development

Chapter Five presented the core of this research. This involved the

software component development process (see Section 5.2) and the details of all

the components that were developed as a part of this research (see Section 5.3).

The software development process was divided into three steps. These were

analysis, design, and implementation. Analysis involves the study of the domainand the identification of the key identities, their functionality, and their

relationships (see Section 5.2.1). The next step (design) involves the generation

of implementation level specifications for the entities identified in the analysis

phase (see Section 5.2.2). The last step is the implementation and testing (see

Section 5.2.3) of the entities. There is communication back-and-forth between

the three steps of the development process.

An analysis of the operational software domain of advanced robotics led

to the identification of sub-domains. Additional domains were also identified.

This included domains whose design was necessary to support the development

of the robotics sub-domains. Other domains were developed purely from a

software engineering view point. These domains supported software components



314

that would facilitate software development (see Section 5.3). A summary of the

selected domains and their functionality is listed in Table 7.6.



315

Domain Functionality Base(see Section 5.3.1)

• Base entity that acts as the parent of all components• Supports functionality common to all components

Mathematical (see Section 5.3.2)

• Support for Linear Algebra constructs• Matrices, Vectors, Tensors, etc. [Strang, 1988]• Provides building blocks for operational software constructs

Robot Data(see Section 5.3.3)

• Support for storing robotics related data and perform errorchecking on the data

• Automatic initialization from data files• Examples are Denavit-Hartenberg parameters, inertia tensors,

center-of-gravity data, etc.

Forward Kinematics(see Section 5.3.4)

• Position-level• Velocity-level• Acceleration-level• Kinematic Influence Coefficients [Thomas and Tesar, 1982]

Inverse Kinematics(see Section 5.3.5)

• Inverse kinematics solution• Resolved rate motion control [Nakamura, 1991]• Direct-search technique [Hooper, 1994]• Hybrid inverse technique (see Chapter Three)• Closed-form and generalized approaches• Level III fault-tolerance

Performance Criteria(see Section 5.3.6)

• Abstract components for performance criteria• Some example performance criteria [Hooper, 1994]• Criteria fusion (see Chapter Three)

Dynamics(see Section 5.3.7)

• Newton-Euler inverse dynamics [Craig, 1986]• Lagrangian dynamics [Thomas and Tesar, 1982]• Complete description of physical plant

Deflection Modeling(see Section 5.3.8)

• Deflection prediction in serial manipulators [Fresonke et al.,1988]

• Deflection due to joint and link compliance• Generalized spring

IODevices(see Section 5.3.9)

• Abstract input-output device classes• Serial-ports• Keyboard

Utility(see Section 5.3.11

• String classes• Timing classes• Error handling

Communication(see Section 5.3.12)

• Inter-process communication• Network communications• Client-server classes using TCP [Brain, 1994]

Other(see Section 5.3.13)

• Key data structures• Container components• Wrapper classes for encapsulating OS functionality

Table 7.6: A Listing of Key Domains and their Functionality.



316

The domains listed in Table 7.6 were further comprised of sub-domains

and software components (C++ classes). These components were connected to

each other through inheritance and containment relationships. Lessons were

acquired regarding domain analysis, design, and management of the software

development process. These are discussed in the following sub-sections.

7.1.4.1. Domain Analysis

A detailed domain analysis is key to the successful design of software.

While conducting this analysis, heed should be given to the current (actual)

functionality desired from the components and the forecasted functionality. The

architecture of the components should be designed to support future additions and

modifications. This is crucial when the domain is based on abstract constructs

and is not fully developed. An example of this is the Performance Criteria

domain that was developed as a part of this research. This domain development

took place keeping in mind that there still was not a fully developed technique for

criteria normalization. In future, an applications developer should be able to

make criteria normalization enhancements with minimal redesign and

implementation.

7.1.4.2. Abstraction Design

The abstraction development process came to the basic conclusion of

“design in parts.” This philosophy has been stressed by designers in all fields.

The adoption of this approach in the component development process stressed the

importance of interface development and specification, and the break down of the

components into sub-components. The granularity of a component was based on

the following “rules of thumb”:

• The interface for a component should fit on a three-by-five inch postcard

[Coplien, 1994].



317

• A component that is an aggregation of other components will be in general

less efficient than a component that provides all its functionality. In areas

where the real-time constraints are stringent, this might be desired. However,

it was realized that breakdown of components offers long-term hidden

advantages of maintainability and reusability. Note that, the decreased

efficiency of an aggregated component will be counteracted by the

advancement in processor technology.

• A component may need to support specific functionality that would not be

needed anywhere else. In this case, it would be appropriate to build that

functionality into the component rather than making a separate entity to

support that functionality. An example explains this scenario. Consider a

software component that is used to read data from a digital bus. The bus

being used here is proprietary and it will not have any future applications. In

the design of the component in question, a more efficient design may be

achieved by embedding the bus-protocol inside the data reading component.

It should be noted that in such scenarios the developer should carefully weigh

the advantages of embedding functionality as compared to modularizing the

functionality.

Software reuse is achieved in object-oriented design through inheritance

and parameterized data types (see Section 2.5.2). Inheritance is successfully used

by incorporating dynamic binding. Under dynamic binding, the correct

functionality is automatically invoked based on the type of the object. Dynamic

binding is achieved in C++ using a mechanism called virtual methods (see

Section 2.5.1.2.5). A call to a virtual function is more expensive (in time) than a

call to an ordinary method. Additionally, virtual methods cannot be inlined to

improve efficiency. In this research, virtual methods were used infrequently.

Their use was based on how critical it would be in the future to modify a certain



318

method. The use of virtual methods was especially limited in areas of hardware

interfacing were deterministic performance was desired.

In a good design, components should have alternative means of

demonstrating their functionality. This aspect was even more crucial for this

research as the software architecture was expected to cut down program

development time and also be applicable to real-time control. One means of

reducing program development time was by using an intuitive (perhaps less

efficient) interface. This interface relied on operator overloading. However, for

real-time control the requirement of efficiency was crucial. This conflict was

resolved by having two different interfaces wherever possible. One interface was

designed for ease of use while the other offered computational efficiency.

An analysis of the application domain created the functional

specifications. The analysis also involved an understanding of possible future

applications of a component. From experience gained through this research, it

was realized that better component design could be achieved by designing them in

isolation. The interface of a component should not be biased towards an

application. This can be achieved by avoiding focus on applications of acomponent while designing it. The focus should be on the functionality of the

component and the best way to expose the functionality. Application specific

interface modifications can be made by developers using any of the reusability

techniques.

7.1.4.3. Organization

Consistency in style and organization of source code increases the

availability of the software and is essential to achieve software reuse. The

software development guidelines developed for this research (see Appendix A)



319

added consistency to the programming style. The source code was organized

using a directory structure (see Section C.3.3) that was parallel to the layout of the

various sub-domains of operational software. It is essential that all developers

that add to this software architecture follow the software development guidelines.

This reduces the effect of individual idiosyncrasies and gives a uniform look and

feel to the system.

The availability of software and its successful release is further dependent

on the configuration management that is in place. The current setup of the

configuration management relies on makefiles and source code control (see

Section C.3.4). Further work needs to be done in this area for better control over

the development and release process.

7.1.5. Summary and Conclusions of the Demonstrations

The purpose of Chapter Six was two-fold. First was the demonstration of

the OSCAR architecture by developing various applications. These applications

demonstrated all aspects of OSCAR. That is, the generalized software

architecture, reusability via inheritance and aggregation, real-time control and

simulation support, manual controller integration, and the development,

execution, and test environment (see Sections 6.2.1 to 6.2.8). In essence, these

applications demonstrated OSCAR’s achievement of all the research goals that

were proposed in Chapter One (see Section 1.2).

The other goal of this chapter was to discuss the validation process for this

research. In the research objectives it was proposed that OSCAR would cut

program development time by 50%. Experiments were conducted with OSCAR

to test this hypothesis (see Section 6.3.1). These experiments involved eight

experimenters. A set of ten experiments were designed in increasing order of

complexity. Seven of the experimenters conducted the ten experiments. The

other experimenter had significant previous robotic software experience and used



320

OSCAR to develop a large-scale application in his/her research area (see Section

6.3.2).

The experiments were conducted over a period of four months. The

averaged evaluation data for each experimenter is given in Section 6.3.3.1. The

weight of each experimenter (computed based on aptitude, motivation,

experience) is also listed in Section 6.3.3.2. The net result of the experiment led

to a comparison of OSCAR with two types of robotic software environments.

These were:

• Mathematical software (for example, Matlab and Mathematica).

• C/C++ robotic software that was previously used at the Robotics Research

Group.

Figures 7.1 and 7.2 illustrate the comparison of OSCAR with the two

systems it was measured against. From the figures it is clear that OSCAR shows

improvement in all aspects it was evaluated in.


0

1

2

3

4

5

6

7

8

9

10


OSCAR

MathematicalSoftware

Figure 7.1: OSCAR Compared to Mathematical Software.



321

The experimental process also resulted in suggestions for improving

OSCAR. The biggest concern expressed by the experimenters was the lack of

documentation. This documentation was developed as a part of this report and

was thus made available only towards the end of the experiments. However, the

C++ header files offered some form of documentation. Besides suggestions, bugs

were found in the OSCAR software components. These bugs were remedied as

the experiments progressed.

7.2. Primary Contributions

The main focus of this research was to develop an operational software

architecture for advanced robots. This involved a detailed study of the domain of

advanced robotics, study of the algorithms involved, study of real-time software,

an in-depth analysis of software design techniques, study of computer technology,

and software development management and organization issues. The primary

contributions of this research are summarized in the following sections.

Ease of Use Generality Organization 1/Code Time 1/Test Time0

1

2

3

4

5

6

7

8

9

10


OSCAR

C/C++ RoboticSoftware Systems

Figure 7.2: OSCAR Compared to C/C++ Robotic Software.



322

7.2.1. Generalized Inverse and Criteria Fusion

This research contributed to the area of criteria-based inverse kinematics.An extension to Hooper’s [1994] technique was developed. This technique was

completely generalized and supported Level III fault-tolerance. Additionally, a

preliminary technique for criteria fusion was developed. The limitations of this

technique basically stressed the need for criteria normalization. The algorithm

developed as a part of this research when combined with the OSCAR architecture

offers an excellent framework and environment for research in level III fault-

tolerance and criteria-based decision making. The developed algorithm was

demonstrated in real-time on a seven DOF arm using three criterion and criteria

fusion. In this case, the application demonstrated a 170-times performance

improvement over Hooper’s [1994] direct-search technique.

7.2.2. OSCAR Architecture

An Operational Software Architecture for Advanced Robotics (OSCAR)

was developed. This framework showed improvement over previously used

robotic software architectures. The improvement shown by OSCAR whencompared to mathematical software is shown in Table 7.7.



323

From Table 7.7 it is seen that OSCAR decreased both coding and

testing time by a factor of greater than three. From this observation it can

be safely said that the program development time saw a reduction of at least

50% as compared to mathematical software systems.

OSCAR was also compared to the existing robotic software at the

University of Texas Robotics Research Group. This software was primarily

written in C and C++. The results of the comparison are shown in Table 7.8.

Criteria Improvement over Mathematical Software

(Matlab and Mathematica)

Ease of Use 1.3 times

Generality 1.5 times

Organization 1.7 times

Time to code 3.3 times

Time to test 3.2 times

Table 7.7: OSCAR’s Improvements over Mathematical Software.



324

Table 7.8 it is seen that OSCAR decreased coding time by a factor of

greater than three. The testing time was also seen to decrease by a factor of

almost two. From this observation it can be safely said that the program

development time saw a reduction of at least 50% as compared to robotic

software that was previously being used at the Robotics Research Group.

OSCAR also showed improvements in its ‘ease of use,’ generality, and

organization. This hypothesis was under test in this research.

The OSCAR architecture was developed using the C++ programming

language. A total of 20,000 lines of high level C++ code were developed (this

included the example applications). A total of 41 classes and 494 methods were

developed.

7.2.3. Validation of Design Philosophy

This research also confirmed the advantages object-oriented design

offered over structured design. Object-oriented design was the major reason why

OSCAR showed considerable improvement over previous efforts. Additionally,

Criteria Improvement over Robotic Software being used at the

Robotics Research Group

Ease of Use 1.3 times

Generality 1.5 times

Organization 1.3 times

Time to code 3.1 times

Time to test 1.8 times

Table 7.8: OSCAR’s Improvements over Existing Robotic Software at the

Robotics Research Group.



325

the advantages of distributed control (as seen from manual controller integration

in Section 4.5) over centralized control were validated.

7.2.4. Development, Execution, and Test Environment

Another contribution of this research was that it provided a framework for

robotic software development. This framework included, software development

tools, software execution environment, and robotic devices for software testing.

A completely integrated and yet distributed environment was developed that

supported real-time control, simulation, manual controllers, and a variety of

robotic devices. Moreover, the effort put into software organization and

management greatly enhanced the availability of OSCAR. Additionally, software

development guidelines were put in place for the Robotics Research Group.

7.2.5. Developer Training

It was realized during the course of this research that the real worth of

OSCAR can only be realized if it can be used to solve “real-world” problems.

This would only be possible if applications developers were trained in the use of

OSCAR. The experiments conducted as a part of this research (see Section 6.3)

not only served the purpose of validating this research, but also were a vehicle for

developer training. Additionally, example application programs were developed

using the OSCAR architecture to facilitate developer training (see Section 6.2).

7.2.6. Management

Besides core research contributions, a major effort was spent in just

keeping “things up and running.” The OSCAR architecture incorporated the

Robotics Research Dual Arm, four manual controllers, four computers, three

operating systems, and multiple users. The presence of many components and

multiple users made the management process complex. However, due to the



326

distinct and distributed nature of these systems, OSCAR was never unoperational.

If the physical robot was not working, a simulation could be used for program

development. If VxWorks was unavailable, control program development could

still take place on the Solaris system.

In summary, a major effort was spent on just managing and nurturing this

system through its infancy. Finally, at this point of time (August, 1996) the

system has reached stability and all the problems are well understood. Most of

these problems are robotic hardware related and are being remedied.

This research would not have been possible without the team-spirit shown

by the people involved in the development of OSCAR. These included people

who were developing applications using OSCAR, developing hardware for use in

the OSCAR environment, and people involved in making high-level decisions

regarding OSCAR’s direction. This effort was a success due to the motivation,

hard-work, and team-spirit of everyone involved.

7.3. Supporting Technologies for Operational Software

OSCAR offers to the robotic software developer an environment that canbe used to develop control programs. OSCAR by itself does not offer a complete

system for robotic application development. Other technologies have to be

developed for the enhancement, use, and support of OSCAR. There are some

areas of robotic operational software that OSCAR does not currently support.

These need to be developed to enhance OSCAR. Other areas need to be

developed that will allow the use of OSCAR. For example, a real-time control

layer needs to be developed. This layer will be used by OSCAR to interface with

actual physical hardware (a preliminary real-time control layer was developed by

Rackers [1996] for this research). Other areas need to be developed to support

the software components that OSCAR presents. For example, OSCAR supports

the generalized inverse formulation. However, as high precision jobs require an



327

exact model of the system, the exact physical parameters of the system are

desired. For this to be possible, robot metrology needs to be addressed. These

technology areas that need development are discussed in detail in the following

sections.

7.3.1. Computer Hardware

OSCAR is a software architecture. It uses computer hardware for

program execution. The design of OSCAR has been based on the assumption

that, computer hardware will continue to improve at the rate predicted (a 100+

improvement in the next five years as predicted by Hooper [1994]). From

industry trends it is seen that the price/performance ratio of computers is steadily

increasing. The performance of personal computers is forecasted at 800 MIPS by

the year 2000 (see Section 2.7). This is encouraging for OSCAR development.

OSCAR will also gain from the advancement in computer architecture. General

purpose multiple processor PC’s are currently available. The advantages of using

a multiprocessor architecture will become evident as the support for multicriteria

decision making increases. In essence, computer hardware is a technology that is

driven by the consumer industry and will greatly improve the performance and

availability of OSCAR.

7.3.2. Operating Systems

An operating system is the software that interfaces with the hardware of a

computer and encapsulates its functionality. All modern day computers come

equipped with an operating system. In fact, most computers offer its users a

choice of operating systems. For example, an Intel-based PC can support

Windows, Windows NT, LynxOS (real-time UNIX), SCO UNIX, etc.

The new generation of operating systems being developed all support

parallel execution of software and also have extensions for symmetric



328

multiprocessing (SMP). An SMP operating system is used in multiprocessor

systems. In a SMP system, a copy of the operating system is supported by each

processor. No processor is the master in such a system. Software programs can

be developed using the SMP systems that allow for automatic allocation of

parallel tasks to different processors. Operating systems like Windows NT and

OS/2 have even further simplified the development of parallel programs. A

parallel program developed for Windows NT will run on a single processor

system or will automatically use all the available processors if run on a multiple

processor hardware [Brain, 1995]. This allows for portability and simplified

program development.

All major operating systems are now 32 bit. This means that data is

processed by these operating systems in blocks of size 32 bit. UNIX workstations

are currently moving to a 64 bit operating system (an example is IRIX 6.0 from

Silicon Graphics). Robotic computations, which are primarily floating point,

greatly benefit from the move to 32 bit and 64 bit operating systems (floating

point numbers are 32 bit or 64 bit in size).

Operating systems have also shown an improvement in their support forreal-time program development. Real-time program development is based on

parallel software execution, priority-based allocation of resources, and

deterministic interrupt handling. Currently, commercial operating systems like

Windows NT and OS/2 do not support real-time software development, though

real-time versions of UNIX are available. The future will see a move towards the

use of commercial operating systems because of their high price/performance

ratio. This will become feasible as these operating systems will further develop

their support for real-time program development.

In summary, operating system technology is also consumer industry

driven and will continue to improve. More will be expected of operating systems.



329

This will allow OSCAR to focus more on robotic software. Utilities for efficient

program development and execution will be a part of the operating system.

7.3.3. Communications

Communications involves data exchange between two computers or

within a computer. Different types of communication mechanisms are used based

on the application. For example, the communication between the system

controller of a robot and the servo controllers is generally tightly coupled and

uses a high-speed bus [Aalund et al., 1993]. Bus technology has seen consistent

improvement. For example, the XT bus used in personal computers in the early

1980’s had a bandwidth of 800 Kbytes/second. Currently, the Turbo Channel bus

used in Digital workstations has a bandwidth of 98,000 Kbytes/second. This is a

122-time improvement. This improvement in bus technology bodes well for

distributed operational software.

Besides the development of bus technology, the robotic industry has seen

the development of standard protocols for communication. Again, these

communications are at two levels. First is the communication protocol for tightly

coupled machines (an example is the coupling between the system controller and

the servo controllers). An example of this is the SERCOS standard. The Serial

Real-time Communication System (SERCOS) standard provides a basis so that

manufacturers can build components (control units, drives, etc.) that can operate

trouble-free with components made by other manufacturers. Thus, SERCOS

defines a uniform interface for dialog between digital drives and control units of

numerically controlled machines [Puls, 1994]. The proliferation of

communication standards gives the system developer a bigger pool to choose

from. Moreover it is seen that a majority of the communication protocols are

being supported on different bus architectures. This again bodes well for the

robotic control system developer.



330

The second form of communication protocol is used between computers

that are loosely coupled. An example of this is two computers on the Internet.

Generally, this type of communication cannot be used for real-time control. The

biggest application of this form of communication is in factory automation

systems. A robotic system controller in a “real” application has to coordinate

with other machines and has to continuously exchange data with them. This type

of communication protocol was used in this research for manual controller

integration and for distributed computing. Various standard software libraries are

currently available that allow world-wide communication between computers.

An example of this is the Transmission Control Protocol (TCP). TCP allows the

transmission and receiving of packets of data between different computers. Using

TCP, data exchange software has been developed that allows for a program to

execute on multiple computers. One such standard is the Common Object

Request Brokerage Agent (CORBA) [Burchard and Feddema, 1996]. CORBA

allows for exchanging objects (from object-oriented programming) between

computers. When an object is passed from one computer to another, the receiving

computer can operate on this object as if it was created over there. Thistechnology simplifies distributed program development. Also, the CORBA

standard hides the differences between the hardware architecture of the computers

exchanging data. An example of this is when data is exchanged between a

Motorola-based computer and an Intel-based computer. In this case the byte

order of the data has to be swapped.

Basically, bus technology, communication protocols, and object exchange

software have shown considerable improvement in the past few years. A big

reason for this is the increase in processor speeds and emergence of object-

oriented design. Robotic software should now be designed to take advantage of

these technologies. This has not been the case in the past. Previously robotic

controllers were specifically developed for each robot. This included the



331

hardware, operating system, communication protocols, and robot programming

languages. The time has come for robotic industry to drive itself from the best in

commercially available technology rather than trying to “patch-up” old

technology to meet customer demands.

7.3.4. Configuration Management Tools for Software

The configuration management of software has one major goal. This is to

have only one version of source code. The configuration management system

should be able to use this source code and build shippable versions for different

platforms and different applications. For example, if an OSCAR control program

is needed for controlling a six DOF arm, with deflection compensation, using a

Windows NT PC, the configuration management should be able to access and

combine the right components to generate an executable program.

The development of OSCAR took place in an academic environment. In

such an environment there are no product release dates, product versions, and

product shipments. For OSCAR to be commercially viable, it is necessary to

develop a configuration management system for software development and

shipment. This technology is well understood by the software industry and tools

are available for configuration control.

OSCAR development environment currently supports some configuration

management. OSCAR can currently be compiled for three operating systems.

These are VxWorks, Solaris, and Windows NT. This is all automated using

makefiles [Oram and Talbott, 1995]. Version control in OSCAR is being

currently implemented using Source Code Control System (SCCS) [Bolinger and

Bronson, 1995].

In summary, configuration control is necessary for development of a

commercial product that caters to different applications. Software tools for

configuration management are commercially available and can be easily



332

incorporated into the OSCAR development environment. Makefile’s and SCCS

are already incorporated in OSCAR. It is seen though that a majority of large

software companies have developed their own configuration control system (for

example, National Instruments). This was done because the commercial systems

were not adaptable to individual needs. This problem will go away in the future.

This is because the software industry is also moving towards “agile

manufacturing.” Applications developers will be able to get software components

from different vendors and assemble them to satisfy their application needs. This

trend bodes well for the future of OSCAR.

7.3.5. Graphical User Interface

A graphical user interface (GUI) is used to provide the man-machine

interface. The OSCAR architecture constitutes the middle layer of robotic

software. The layer above this is the man-machine interface. This includes the

robot programming language. Current trends in industry show a move towards

visual programming. These programming systems allow the applications

developer to generate control programs using a GUI. This approach to program

development has also been used in robotics [Kapoor, 1992]. Additionally, the

robot controller available from Cimetrix Incorporated [1996] also supports a GUI

based robot programming environment. LabView from National Instruments

[1996] is another example of a visual programming environment. It allows the

user to graphically connect sub-systems to generate application programs.

Extensive work has been done in the research community in developing

graphical user interfaces for man-machine software. Some examples of these

systems were discussed in Chapter Two (Sections 2.6.2.2 to 2.6.2.5). OSCAR

could be combined with these systems to offer a complete solution. However, the

robotic GUI systems developed in academia are generally based on proprietary

software environments. This limits their portability and future growth potential.



333

A better approach would be to use a commercial GUI framework and add robotic

specific GUI components to it. An example of this is the LabView software

environment from National Instruments [1996]. This software is the de-facto

industrial standard for instrumentation. LabView is based on visual

programming. In this environment, the application developer connects various

sub-systems graphically. Additionally, LabView provides a rapid-prototyping

environment for GUI development. Support is currently being added to LabView

to assist in factory automation. This includes support for programmable logic

controllers (PLC), various industrial buses, motion control, data-acquisition, etc.

All these technologies are used in robot system integration. In essence, the use of

commercial systems for robot software development is along the lines of this

research, that is, software reuse and incorporation of the latest in commercial

technology.

7.4. Future Work

This section provides a roadmap for future development of robotic

software. This includes the enhancements that have to be made to OSCAR.These enhancements will include the development of new sub-domains within

OSCAR and also the improvement of the current components in OSCAR.

Additional work also needs to be done in the development of the other

layers of software that are involved in system control. These are the man-

machine interface and real-time control.

Besides system control, effort needs to be directed at the development of a

software architecture for actuator level control. A software architecture that

encompasses all possible manual controllers also needs to be developed. Further,

a software system for maintenance of machines needs to be developed.

The previous paragraphs suggested other domains that need development.

Once a large number of components are available to the applications developer,



334

the next step is the selection and assembly of the components. A software system

needs to be put in place for this purpose.

The ultimate test of a robotic software system would be its applicability to

manufacturing cell control. These manufacturing cells should be based on jigless

and fixtureless manufacturing, reduced integration time, reduced robot

programming time, and a predictable maintenance schedule. Towards the end,

this section addresses some of the issues involved in manufacturing cell

development. The last section provides a time-line for the development of the

technologies that were addressed in this section.

7.4.1. Other Operational Software Domains

OSCAR provides a framework for robotic software development.

OSCAR currently addresses the issues involved in operational software of

advanced robots. Not all domains that are present in operational software were

addressed by OSCAR. The following section discusses the other sub-domains

that need development or enhancements.

7.4.1.1. Obstacle Avoidance

The importance of on-line obstacle detection and avoidance is expected to

increase rapidly in the near future. This is going to become extremely necessary

as manufacturing shifts its focus to an agile system comprised of manufacturing

cells.

The software system for obstacle avoidance consists broadly of two sub-

systems. These are the obstacles and the algorithm for avoiding obstacles. The

obstacle avoidance domain should provide the robotic software developer a

flexible and general means of describing obstacles. The algorithm used for



335

obstacle avoidance should also be general. These software issues for these two

systems are described below.

7.4.1.1.1. Generalized Obstacle Description

Perry [1995] identified key shapes that constituted an obstacle. These

were cylinders, cones, double-cones, and spheres. All these shapes can be

addressed as a part of an inheritance hierarchy in object-oriented design. New

shapes could also be created by aggregating the existing shapes. A class

hierarchy for these shapes has already been created for 3D graphics software

development (see Appendix D). This class hierarchy could be used to express

obstacles.

Two different types of obstacles will have to be provided. These will be

static obstacles that do not change shape. The design of the software for these

obstacles should be tuned towards a faster computation of the distances of these

obstacles from the robot. The other type of obstacle will be reconfigurable. This

type of obstacle will change its shape and will be used to express systems with

moving parts (for example, another robot). The software for reconfigurable

obstacles should be tuned towards efficient reconfiguration and distance

calculation.

7.4.1.1.2. Generalized Algorithm for Obstacle Avoidance

The preliminary algorithm developed by Perry [1996] for obstacle

avoidance was based on the use of kinematic influence coefficients [Thomas and

Tesar, 1982]. Using these, distance functions were formulated to determine the

distance between a serial robot and obstacles within its workspace. Further, this

algorithm was incorporated into an initial criteria-based decision making scheme.

For a given set of joint-space options that satisfied a particular end-effector

constraint, the obstacle avoidance criterion ranked these options based on the



336

maximum distance from obstacles. The joint-space option that had the maximum

distance from the obstacle was the selected solution.

This algorithm fits directly into the OSCAR architecture. Components are

already present in OSCAR that support the computation of first and second-order

kinematic influence coefficients. The Performance Criteria domain allows the

efficient creation of new criteria. For the obstacle avoidance criterion, the only

functionality that has to be added will be the calculation of the distance of a robot

from the obstacles. The computation of forward kinematics solution, the ranking

of the joints-space options, and the fusion of criteria will be automatically

handled by OSCAR.

In summary, two steps have to be accomplished for the obstacle avoidance

domain. These are, the development of a class hierarchy to express different

shaped obstacles and the development of an obstacle avoidance criterion.

7.4.1.2. Performance Criteria

The Performance Criteria domain was developed as a part of OSCAR.

However, only three performance criterion were developed. VanDoren [1992] in

his Masters thesis identified twenty-nine different criteria. These criteria need to

be implemented. The implementation of these performance criterion will take

place within the framework provided in the Performance Criteria domain. The

developer will have to only provide the functionality for computing the criterion

value for a particular joint-space option. The functionality for ranking the various

criteria values and for criteria fusion will be common to all performance criteria.

Tables 7.9 to 7.12 list the criteria that need development and the OSCAR

components that they will use. All the new performance criteria components will

be derived from the RRPerformanceCriteria component (see Section 5.3.6.1).

The performance criteria are further divided into geometric, force/torque, kinetic

energy, and compliance. Refer to Hooper [1994] for further details on the



337

individual criteria. The following sub-sections discuss the various types of

performance criteria and their dependency on OSCAR.

7.4.1.2.1. Geometric Performance Criteria

Table 7.9 shows the various geometric performance criterion. These

criterion are dependent on the first and second-order kinematic influence

coefficients. The RRFKJacobian (see Section 5.3.4.2) and RRFKVelocity (see

Section 5.3.4.4) provide the first-order kinematic influence coefficients. The

RRFKAcceleration (see Section 5.3.4.5) provides the second-order influence

coefficients.

7.4.1.2.2. Force/Torque Performance Criteria

Geometric Performance Criteria OSCAR Components to Use

(all use

RRPerformanceCriteria)

Singularity detection RRFKJacobian

Dexterity RRFKJacobian

Velocity transmission RRFKJacobian, RRFKVelocity

Force and torque transmission RRFKJacobian, RRFKVelocityJacobian Frobenius Norm RRFKJacobian, RRFKVelocity

Rate of change of singularity detection RRFKAcceleration

Rate of change of dexterity criterion RRFKAcceleration

End-effector velocity-induced jointacceleration

RRFKAcceleration

Joint velocity-induced end-effectoracceleration

RRFKAcceleration

Table 7.9: OSCAR Components Required for the Development of Various

Geometric Criteria.



338

The other category of performance criteria are based on the dynamic

models of the forces and torques within the robot structure [Hooper, 1994].

These criteria are listed in Table 7.10. Along with this are listed the OSCAR

components that are required for the implementation of these criteria. Like the

geometric criteria, the force/torque criteria will also be derived from the

RRPerformanceCriteria component. These force/torque criteria are dependent on

the first and second-order kinematic influence coefficients. The RRFKJacobian

(see Section 5.3.4.2) and RRFKVelocity (see Section 5.3.4.4) provide the first-

order kinematic influence coefficients. The RRFKAcceleration (see Section

5.3.4.5) provides the second-order influence coefficients.

Force/Torque Performance Criteria OSCAR Components to Use

(all use RRPerformanceCriteria)

Dynamic coupling RRFKVelocity, RRFKAcceleration

Actuator torque RRFKVelocity, RRFKAcceleration

Equivalent end-effector forces RRFKVelocity, RRFKAcceleration

End-effector actuator torque RRFKVelocity, RRFKAcceleration

Rate of change of actuator torquecriterion RRFKVelocity, RRFKAcceleration

Rate of change of equivalent end-effectorforces criterion

RRFKVelocity, RRFKAcceleration

Rate of change of end-effector spaceactuator torque criterion


Velocity-induced actuator torque RRFKVelocity, RRFKAcceleration

Velocity-induced equivalent end-effectorforces


End-effector space velocity-inducedequivalent actuator torque


GH norm RRFKVelocity, RRFKAcceleration


Force/Torque Criteria.



339

7.4.1.2.3. Kinetic Energy Performance Criteria

The primary goal of kinetic energy performance criteria is theminimization of the total kinetic energy of the system. This is extremely

important for high-speed precision operations. Table 7.11 lists the various kinetic

energy performance criteria. These criteria are dependent on the first and second-

order kinematic influence coefficients, the inertia matrices, and the inertia power

matrices [Hooper, 1994]. The RRFKJacobian (see Section 5.3.4.2) and

RRFKVelocity (see Section 5.3.4.4) provide the first-order kinematic influence

coefficients. The RRFKAcceleration (see Section 5.3.4.5) provides the second-

order influence coefficients. The RRIDLagrange (see Section 5.3.7.3) component

provides the inertia matrix and inertia power matrices.

7.4.1.2.4. Compliance Performance Criteria

Table 7.12 lists the compliance performance criteria and the OSCAR

components that they use. The compliance criteria describe the robot’s ability to

perform precision operations under load. Refer to Hooper [1994] for details on

Kinetic Energy Performance Criteria OSCAR Components to Use

(all use

RRPerformanceCriteria)

Joint space kinetic energy RRFKVelocity, RRIDLagrange

End-effector space kinetic energy RRFKVelocity, RRIDLagrangeRate of change of joint-space kinetic energy RRFKVelocity, RRIDLagrange

Rate of change of end-effector space kineticenergy

RRFKVelocity, RRIDLagrangeRRFKAcceleration

Kinetic energy partition values RRFKVelocity, RRIDLagrange


Kinetic Energy Criteria.



340

the various compliance criteria. The compliance criteria use the first-order

kinematic influence coefficients, and the inverse dynamics formulation. The first-

order kinematic influence coefficients can be obtained from RRFKVelocity (see

Section 5.3.4.4). The joint torques can be obtained from RRIDLagrange (see

5.3.7.3) or RRIDNewtonEuler (see Section 5.3.7.2). The overall deflection of the

end-effector and a description of the generalized spring can be obtained from the

RRDeflection component (see Section 5.3.8).

7.4.1.3. Other Enhancements to OSCAR

The first version of OSCAR is currently being used at the Robotics

Research Group. The most extensively used components are the mathematical,

kinematics, performance criteria, and communication components. The interface

and functionality of these components has been well tested and has almost

reached stability. The domains of deflection modeling and inverse dynamics havebeen tested but have not been used for real-time control. This has to be done in

the future. This may entail additional interface and functional development.

Compliance Performance Criteria OSCAR Components to Use

(all use RRPerformanceCriteria)

Oscillation RRFKVelocity, RRDeflection

System stiffness RRFKVelocity, RRDeflection

System potential energy RRFKVelocity, RRIDNewtonEuler,RRIDLagrange, RRDeflection

Potential energy partition values RRFKVelocity, RRIDNewtonEuler,RRIDLagrange, RRDeflection


Compliance Criteria.



341

Under kinematics, software components are provided that can be used for

a criteria-based generalized inverse. These components inherently support level

III fault-tolerance functionality. However, complete testing of the level III fault-

tolerance support is needed. This is currently being accomplished at the Robotics

Research Group.

7.4.2. Other Software Architectures for System Level Control

Besides operational software, there are other areas of system control

software that need development. The two other layers of system control software

are the man-machine interface and the real-time control. The following sections

discuss some of the issues involved and offer suggestions in the development of a

software architecture for these layers.

7.4.2.1. Software Architecture for Man-Machine Interface

The man-machine interface for robots includes the robot programming

language and the GUI for commanding the robot. Academic research has led to

the development of a variety of robot programming languages. These range from

very simple interpreted languages to task-level languages. Standard programming

languages like C, Ada, etc. have also been used for robot programming.

Currently, it is seen that there is no standard for robot programming languages.

Commercially robotic controllers are currently offering the robot programmer

with a choice of robot programming environments. For example, the SC 4000

system controller from Cimetrix Incorporated offers three different environments

for robot programming. One of these is a GUI based robot programming

environment.

The robotic industry has a lot to leverage from the commercial software

industry when it comes to man-machine interfaces. The proliferation of

windows-based operating systems is evident from the boom in the PC market.



342

The availability of such systems has made available a wide range of GUI

development tools. Additionally, a majority of visual programming environments

are currently available. These environments allow the generation of programs

using a GUI and without writing any code.

The following steps should be taken for the development of a man-

machine interface:

• Commercially available and popular robot programming languages should be

studied. Lessons learned from these robot programming languages should be

used to further develop a teleoperator language to support redundant arms,

decision-making, and fault-tolerance.

• This robot programming language should be incorporated in a commercial

visual programming environment. The visual programming environment that

is selected should be geared toward hardware interfacing and machines.

LabView from National Instruments [1996] is an example of this.

Enhancements should be made to the selected visual programming

environment to add support for advanced robotics.

• The man-machine interface software developed at Sandia National

Laboratories (see Sections 2.6.2.2 to 2.6.2.4) should be reviewed in detail.

Currently, this system is geared more towards standard industrial robots. If

this system is extensibility and portable it could offer a solution for man-

machine interface software.

7.4.2.2. Software Architecture for Real-Time Control

The real-time control layer is the lower-most layer of robotic system

control software. This is the layer which interfaces with external hardware, sends

set-points to the servo controllers, accepts feedback and may be responsible for

running control loops.



343

A preliminary real-time control layer was developed by Rackers [1996].

This layer is currently used by OSCAR to communicate with physical hardware.

However, this layer is specific to the system being used and does not offer much

extensibility. A reusable and general real-time control layer needs to be

developed. This layer should offer a standard interface to OSCAR. The key

factors to consider while designing this layer are as follows:

• The real-time control layer has to respond to multiple external events. These

events could be random and may occur asynchronously. A parallel execution

environment is best suited to the development of this layer and is supported

by most real-time operating systems. Furthermore, most operating systems

offer tools to simplify parallel program development. An example of this is

the Wind Foundation Classes from WindRiver Systems.

• A major part of the real-time layer is hardware interfacing software. In

general, it is undesirable to communicate with hardware directly. Most

operating systems (for example, Windows NT and UNIX) would actually not

allow an applications program to do this. The safe and correct way to access

hardware is through device drivers. Device drivers provide a uniform

interface to the hardware and also allow for safe access. For example, if a

device driver is being used to access a serial port by one program, another

program would be denied access to the serial port until the first program has

completed its operation. Thus, before the development of real-time control

layer is undertaken, heed should be given to the availability of device drivers.

• Another requirement of the real-time layer is communications and

multiplexing. The system controller generally communicates with the servo

controllers over a high-speed bus. Moreover, the same bus might be used by

more than two devices to communicate. In such a case the communication

has to be multiplexed.



344

Keeping in mind the above mentioned functionality of the real-time

control layer, a preliminary identification of sub-domains has been done. These

are listed below:

• Class structure for input/output devices. These could be boards, ports,

communication protocols, etc. This class structure should be designed

keeping in mind the portability of the system. The real-time layer should be

able to maintain the same interface when ported to another operating system.

• A class structure for encapsulating the functionality of the operating system

needs to be designed. This would include tasks, synchronization mechanisms

(semaphores, etc.), inter-task communication mechanisms (shared memory,

pipes, mailboxes, etc.). However, the development of this class structure may

not be required as most operating system vendors offer a class library that

encapsulates operating system functionality.

• System controllers for current industrial robots have minimal communication

traffic with the servo controllers. This leads to a simple communications

software architecture. However, advanced robots are going to be

characterized by fault-tolerant actuators. These actuators will have redundant

sensors and will provide a functional map that will allow for their

performance prediction. Information regarding temperature, voltage, current,

torque, etc. will be generated inside the actuator. This information in some

cases will have to be delivered to the system controller in real-time and a high

rate (greater than 100 Hertz). This would put unprecedented demands on the

communication system. The real-time control layer will have to address these

issues.

7.4.3. Software Architectures in Other Domains

OSCAR addressed the software issues involved with system control of

advanced manipulators. The issues involved with servo control of actuators were



345

not addressed. Further, OSCAR supported software for manual controller

integration. However, a systematic architecture that represented all classes of

manual controllers was not developed. Thus, future work needs to be pursued in

the development of software architectures for actuator control and manual

controllers. This is discussed in the following sections.

7.4.3.1. Reusable Software Architecture for Actuator Level Control

An actuator is a self-contained prime-mover. For example, an electric

motor driven actuator may comprise of a motor, gear-train, sensors, a brake, a

clutch, and also the servo-level control hardware and software. Just as this

research developed an architecture for operational software of advanced robots, a

software architecture for controls of actuators is desired. This architecture should

serve the purpose of a most basic actuator and should be extensible enough to

support advanced actuators that could be used in space. The following paragraph

discuss the key characteristics of advanced actuators [Tesar, 1996]1. This

discussion will provide a preliminary analysis of the problem domain. Based on

this analysis, suggestions will be made regarding the design of the software

architecture.

7.4.3.1.1. Architectural and Functional Analysis of an Advanced Actuator

This section discusses the key functionality of an advanced actuator.

Along with the functionality, architectural issues that will have an impact on the

software architecture are also discussed. This discussion is presented below:

1 Dissertation on high-resolution position sensing system in progress by Brent Nowak at the




346

• Simple actuators use only one sensor as a basis for control. This is usually

a position sensor (encoder or resolver). Also, these actuators are primarily

based on a simple control scheme such as PID control.

• Advanced actuators will be based on multiple sensors. Varied sensor

information will be essential for implementing advanced non-linear

control schemes such as model-based control. By fusing the sensory

information with an efficient model of the system, higher performance

will be achieved1.

• Enhanced performance will be the key advantage of an advanced actuator.

The same actuator will be able to use the input sensory information and

reconfigure its control scheme to respond to application need. For

example, for high-speed assembly tasks, the control scheme will support

rapid response. For precision jobs, the control scheme will support

disturbance rejection and high-accuracy2.

• Currently, ten different types of sensors are proposed in an advanced

actuator. These sensors along with their key characteristics are listed

below:

a. position up to 22 bit accuracy,

b. velocity advanced tachometer,

c. acceleration accelerometer,

d. torque up to 12 bit accuracy,

e. temperature primarily in motor,

f. vibration to sense wear damage,

g. sound to sense incipient failure,

h. voltage to describe motor operation,

i. current to describe motor operation,

2 Dissertation on actuator control issues in progress by Eric Scott at the Robotics Research Group



347

j. magnetic field to describe motor operation. [Tesar, 1996]

• Condition-based maintenance will be achieved by these actuators by

comparing an accurate model reference of the actuator with a sensor

reference. This comparison will provide a time-sheet for maintenance3.

• Actuators for space will support fault-tolerance. Fault-tolerance will be

achieved by duality in every active component such as motors, gears,

trains, etc. [Iaconics, 1991].

• As mentioned earlier, an advanced actuator will be sensor intensive. This

will create an information overload. If all this information had to be

communicated to a computer, a very high speed bus would be required.

This coupled with the power cables will greatly increase the cabling

requirements. This problem can be addressed by embedding the control

hardware and software inside the actuator. Thus, advanced actuators will

support local digital controllers (see Section 2.3.1.2 for localized digital

control)4,5

. [Tesar, 1996]

7.4.3.1.2. Design Suggestions for Actuator Control Software Architecture

The previous section presented an analysis of the functionality and

architecture of an advanced actuator. This section offers some suggestions for

designing a software architecture for these machines. The design suggestions are

broken down into sub-domains. These domains and the inter-connections

between them are graphically illustrated in Figure 7.3 and are the execution

3 Dissertation on condition-based maintenance in progress by Augustin Vasquez at the Robotics

Research Group4 Dissertation on embedded controller design in progress by Joseph Geisinger at the Robotics

Research Group

5 Master thesis on system design criteria in progress by Edward Benson at the Robotics Research

Group



348

environment, sensors, control schemes, mechanical components, and system

modeling. These sub-domains are discussed below:


As mentioned in the previous section, an advanced actuator will

preferably have an embedded digital controller. This controller will have

stringent space and weight constraints. This will result in minimal memory and

execution performance. As such this system will not be able to support a

software development environment. Thus, a cross-development environment will

be best suited for this system (see Section 4.1.2 for details on cross-development

systems).

An advanced actuator system will be comprised of mechanical sub-systems that will all function in parallel. For example, motor commutation will

be taking place while position sensor information is being read or system model

data is being analyzed. A parallel software execution environment is best suited


Sensor Data

ReductionSensors

Reconfigurable Controls

Motion ControlSystem

Modeling

Fault-Tolerance

Sensor

ModelCommunications

Mechanical

Sub-Systems

Figure 7.3: Sub-Domains of the Actuator Control Software Architecture.



349

for such a hardware system. Most real-time operating systems support a parallel

execution environment.

An advanced actuator is proposed to have ten sensors. These sensors will

be read continuously. However, all the data generated from these sensors will not

be equally important. The computer resources of the actuator should be

prioritized based on the importance of a particular sensory input. This

prioritization should be reconfigurable in real-time. For example, an actuator

running a servo control loop at a rate of 2000 Hertz may require a dynamic

reconfiguration of system resources every 0.5 milliseconds. An example of the

need for dynamic reconfiguration occurs when the temperature sensor gives an

abnormal reading. At this point the priority of the system resource dedicated to

analyzing the data from the sound sensor should increase. This way, by fusing

the temperature data and the sound data a specific decision could be made about

an impending fault. The priority based allocation of resources is another

characteristics of real-time operating systems.

The data being generated inside an actuator will have to be handled in

real-time. For example, for an actuator with a 2000 Hertz servo-loop, externalevents will have to be handled within 0.5 milliseconds to maintain control

stability. Deterministic event handling is another characteristic of real-time

operating systems. Again, event handling should also be based on priority. Some

events would be more crucial for actuator operation than other events.

Communications

This domain will support software that will allow for communication with

the system controller. The communication domain will interpret the data received

from the system controller and pass it on to the reconfigurable control domain.

Device drivers for various communication protocols will be included in this

domain. This domain will also include components that will allow

communication between different sub-domains of the actuator control software.



350

An example of this would be shared-memory and message passing. The

communication domain will rely heavily on the operating system constructs to

support various communication protocols.

Reconfigurable Controls

This domain will implement various control schemes. Examples of these

are PID, model-based, adaptive, optimal, etc. These control schemes will further

rely on input from the system modeling domain for performance maximization.

The fault-tolerance sub-domain will inform this domain regarding any changes to

the system configuration. The sensor data reduction sub-domain will present

sensory input in a consistent and simplified format to this domain. The output of

this domain will be sent to the motion control sub-system.

Motion Control

The motion control sub-system is responsible for generating current and

voltage commands that are sent to the motors. Algorithms for control of different

types of motors will be implemented here. For example, for a brushless dc motor,

various commutation schemes will have to be implemented. For stepper motors,

various stepping schemes, for example, micro-stepping will have to beimplemented. Additionally, the motion control sub-system will also implement

various motion profiling schemes. An example of this is the trapezoidal velocity

profile. The motion control sub-system will output its command to the

mechanical system. The mechanical system will include the motor, the brake,

and the clutch.

Sensors

Sensors will play a key role in the development of advanced actuators.

The multitude of sensors will lead to a confusing environment that would produce

more information than could be analyzed. This is where a well designed layered

software architecture could simplify things. The ten different sensor types were

discussed in the previous sections. A software architecture has to be designed



351

that encompasses all different types of sensing, and also different types of sensors

for each sense type. For example, an abstract software component whose

interface reflects the functionality of position sensors could be created. This

component should define the interface for all possible position sensors. Derived

from this component should be specializations of a position sensor. Examples of

these would be encoder, potentiometer, etc. Similar abstract types will have to be

created for all other sensors. The advantage of this would be that the type of a

sensor may be swapped without changing the architecture and connectivity of the

remaining software. Components from this domain will be used by sensor data

reduction and for generating a sensor model of the system.

Sensor Data Reduction

The advanced actuator has ten different sensors. Ten different outputs

will be generated by these sensors. Not all of these outputs will be used at any

given instance. Different sensor outputs will be selected based on the control

scheme being used. Also, the output of two or more sensors may have to be

combined to construe a logical result. This is what is referred to as sensor data

reduction or sensor fusion. A software architecture and algorithms have to bedeveloped for logical sensor fusion and data reduction. The output of sensor data

reduction will be used by the reconfigurable controls to provide feedback into the

system. Also, using the reduced sensor data, a model of the system will be

generated. This will be referred to as the sensor model.

System Model

The purpose of this domain is the real-time computation of the system

model. This system model will be formulated using as-built parameters of the

robot. The system model will further draw on the mechanical sub-system models

to build a complete model. The software architecture for the system model

should be general enough to apply to a large variety of actuators.

Mechanical Components



352

The mechanical components domain will contain software components

that emulate and interface to the mechanical hardware. For example, in this

domain there may be a software component called “Brake.” This component will

be a abstract component that defines the functionality of all types of brakes.

Additionally, this component will have functionality to access the parameters of a

brake. These parameters will be used by the system model sub-domain to create a

model reference. Thus, this domain will provide abstract components for all

mechanical sub-systems. Specific functionality for these sub-systems will be

added based on the particular type of sub-system used. For example, when a

particular brake is added to the actuator, a new software component that

encapsulates its functionality will be defined. This component will be derived

from the abstract brake component and it will inherit its interface and some of its

functionality.

Fault-Tolerance

A software architecture for the fault-tolerance domain will have to be

developed for actuators to be used in space. The purpose of this domain would be

to detect incipient faults, identify these faults, and take remedial action. Thefault-detection will take place by continuously comparing a sensor model of the

system to a mathematical model of the system. Discrepancies in the comparison

will be used to identify faults. This domain will also contain software

components for fault recovery. The fault-recovery component will inform the

reconfigurable control domain of the change in the system after a fault was

detected6.

7.4.3.2. Software Architecture for Manual Controller Integration

6 Dissertation on fault-tolerance in progress by Natalia Sharygina at the Robotics Research Group



353

This research incorporated manual controller integration into the OSCAR

architecture. However, all the manual controllers that were used had software

specifically developed for each of them. There was little software reuse. Also,

each manual controller had its own interface. It is desired that a software

architecture be developed that incorporates all classes of manual controllers. This

architecture will include a set of abstract components that define the interface for

using all manual controllers.

There are two types of manual controllers. The first one is similar to a

joysticks and can be used only for open-loop control. The other one includes

force-reflection. The software architecture should define the interface for both

types of manual controllers. Once this interface is defined, new components can

be created that have the same interface but encapsulate functionality specific to

particular manual controllers. The work done by Peterson [1996] should be used

for detailed analysis of the domain and design of the software architecture7.

A preliminary class hierarchy for this architecture is shown in Figure 7.4.

In this class hierarchy the Manual Controller base class defines the interface for a

open-loop manual controller (the interface is italicized). From this class arederived the Keyboard and the TeachBall (see Section 4.6). Both the computer

keyboard and the TeachBall can be used to control robots in open-loop. The

Force Reflecting manual controller is derived from Manual Controller base class.

Here the interface for reflecting forces is added. From the Force Reflecting

controllers are derived the Robot Arm Type controllers and the PerForce

Controller. The PerForce Controller class adds specific functionality to deal with

the Cybernetics PerForce controller (see Section 4.6). The Robot Arm Type

controller will use OSCAR for computing the forward kinematics solution and the

7 Masters thesis on dual-force sensing for manual controllers in progress by Robert Hester at the




354

Jacobian matrix. This will be based on the DH parameters of the manual

controller. The Jacobian matrix will be used to map the hand to joint torques and

forces. From the Robot Arm Type controller, two specific classes are derived.

These support the TOS manual controller and the Kraft manual controller (see

Section 4.6).

7.4.3.3. Software System for Condition-Based Maintenance

The advanced robotic software system described in this research will draw

on the latest in mechanical hardware, computer hardware, and software

technology. The development of such a system will be a costly endeavor. To

keep such a system continuously operational, a condition-based maintenance

system needs to be developed. This system will draw on the resources provided

Manual Controller

• Initialize

• ReadPosition

• ReadButtons

Force Reflecting

• SetForces

Robot Arm Type

TeachBallKeyboard

TOS Controller Kraft Controller

PerForce Controller

Figure 7.4: A Preliminary Class Hierarchy for Manual Controllers.



355

by OSCAR and the real-time control layer to produce a time-sheet for

maintenance.

The condition-based system will consist of a high-speed archiver (a

database) that will be used to store operational history of a system. The

condition-based maintenance system will continuously (once very five seconds)

monitor the sensory input coming in from the real-time control layer. It will also

gather the mathematically modeled state of the system from OSCAR. Both the

mathematical model information and sensor information will be archived and also

analyzed for discrepancies. Discrepancies in the sensor information and the

model information will warn about an impending failure. An empirical analysis

of the archived data will be used to determine detailed information about the

impending fault. The advantage of archiving data is that the more a machine is

used, the better understood will be its behavior.

7.4.4. Agile Manufacturing of Software

Any mature industry is characterized by a component industry. However,

for effective use of available components, it is important to have a process in

place for component selection and component assembly [Yeh, 1993]. This has to

be achieved for robotic software also. OSCAR provides some of the components

for robot control. However, the component selection is currently left to the

applications developer. The assembly of these components is also done by the

applications developer. To automate the component selection and assembly

process, future work needs to be done in the following areas:

• Component selection system.

• Component assembly system.



356

The software components combined with the component selection process

and assembly process will offer an environment for agile manufacturing of

software for system controllers. This concept is illustrated in Figure 7.5. The

input into this system are the application requirements. The application

requirements are generated from application components. For example, a high-

speed assembly operation that also has a force-fit task will comprise of two

components. These will be ‘high-speed’ and ‘force-fit.’ Based on the application

components, an optimized application process will be designed. At this point

there is refinement and testing of this process. The specifications of the

application process are then passed to the component selection and componentassembly systems. These systems are explained below:

7.4.4.1. Component Selection System

Application

Components

SCAD

Man-machine Interface

Components


Components

Real-time ControlComponents

Application

Process

(re)design

Software

Development/

Integration/

Assembly

Integrated

Target

Application

Prototyping/

Refinement

Prototyping/ Refinement/

Testing

Figure 7.5: An Agile Software Manufacturing Framework for System

Control Software.



357

The information generated by the application process design is passed to

the software components selection sub-system (SCAD). SCAD stands for

software CAD and it allows the optimal selection of software modules from the

three layers of system control software. Internal to SCAD, refinement and testing

of the selected software modules takes place. This testing should not be confused

with the unit testing of the components. Unit testing of the components had to be

accomplished after component design. The testing taking place inside SCAD

validates the suitability of a component for the application process (For details on

how SCAD fits into the complete robotic system design tool see Section 2.1).

7.4.4.2. Component Assembly System

The next step after selection of components by SCAD is their assembly.

The assembly of these components will depend on the selected components and

the application process. Currently, this is done manually by the program

developer. In the future this system should include an automatic code generator.

This generator should be able to create a code framework into which the selected

components will fit. The generated code will then be tested and finally a target

application will be created.

Commercially, there are systems available that assist in component

assembly. Most of these systems are used in visual programming environment

such as LabView [National Instruments, 1996] and Microsoft Visual C++.

However, these systems are not intelligent enough to assist in component

selection. The user has to specify the components to use and usually has to

connect them together (visually). Research at Carnegie Mellon University has led

to the design of a similar system (as shown in Figure 7.5) for computer design

[Birmingham and Gupta, 1988]. This system (called MICON) is an integrated

collection of programs that automatically synthesize small computer systems

from high-level specifications. MICON is based on a knowledge based synthesis



358

tool and an automated knowledge acquisition tool. A database and a data

management tool are integrated into this system.

7.4.5. Software Organization and Management Process

The lessons acquired during the course of this research pointed out the

importance of software organization and management of the development

process. For this purpose, software development guidelines were put in place for

the Robotics Research Group (see Appendix A). However, this was the first

attempt at major software development. The needs at the Robotics Research

Group will change as the size of the software increases and more developers start

using OSCAR. The complexity of managing this process will also increase as

more hardware platforms and operating systems will be supported. The software

development guidelines will have to be continually updated and enhanced.

Currently, the software development is managed by makefiles [Oram, and

Talbott, 1995]. Source code control is useful for maintaining older versions,

documenting changes, and allowing multiple developers to work with the same

source code [Bolinger and Bronson, 1995]. A preliminary application of source

code is already in place. However, a complete application of this needs to be

done. Further, the makefiles have to be enhanced to support software

development for Windows NT. Currently, the makefile support development for

VxWorks and Solaris operating systems. For this to be possible, Windows NT

PC and the SUN Workstation will have to share source code.

7.4.6. Manufacturing Cell Development

The culmination of this research and the proposed future work will be a

meaningful application. Manufacturing cells provide an ideal environment for

this application. Manufacturing cells bring us a step closer to achieving the goals

of agile manufacturing. Agile manufacturing focuses on fulfilling orders,



359

whereas mass production manufacturing is focused on stocking and selling.

According to Yeh [1993], “the key to success in agile manufacturing enterprise is

to bring out totally new products rapidly, while maintaining high quality by

incorporating reprogrammable, reconfigurable, continuously changing production

systems within an information-intensive manufacturing system.” In such a

system, the process and its supporting production system adapts to customer

demand changes to accommodate new products.

Manufacturing cells represent the integration of all component and system

level technologies. A manufacturing cell provides a self-contained environment

that is capable of process control, configuration management, rapid product

change-over, and quick change-out of cell modules for repair. This has to be

done at reduced costs and enhanced performance to make it feasible. An example

of a airframe assembly cell is shown in Figure 7.2. This cell has a total of forty

DOF consisting of two active assembly robots, two supporting force robots, and

four rigidized fixturing robots. All these robots have been assembled from

standard modules to meet application demands.



360

Another example of a manufacturing cell consists of a 40 DOF cell that

includes a seventeen DOF Robotics Research Dual Arm robot, a T3-786

Cincinnati Milacron Industrial robot, a six DOF PUMA robot, an overhead

gantry, and a six DOF robot suspended from the gantry. The prototype design of

this cell is shown in Figure 7.3. This cell is currently under development at the

University of Texas, Robotics Research Group. The immediate applications that

this manufacturing cell will support are precision light machining, precision

airframe assembly, modular low-cost robot welding for shipbuilding, and

complex assembly in cluttered environments.

Figure 7.6: Forty DOF Handling Cell for Precision Airframe Assembly.



361

A manufacturing cell can serve different types of applications. Based on

the application, manufacturing cells will draw on all aspects of OSCAR and the

proposed future work. For example, precision applications will use a precisely

calibrated robot. This robot will require an inverse kinematics method general

with respect to geometry. Also, as manufacturing cells will support

reconfigurability, the software should be general to support all possible

configurations. Complex assembly tasks will require that the robot operate in a

cluttered environment. This will involve the robot reaching into a “tight” space or

Figure 7.7: A Prototype Forty DOF Manufacturing Cell.



362

reach around an intermediate object. A redundant arm will be needed in this

application. The software should be able to support the kinematics of this arm.

Moreover the kinematics should support obstacle avoidance.

7.4.6.1. Influence of This Research on Manufacturing Cell Development

This research was based on developing software components that could be

used by a software selection system that was based on task requirements. This

concept was a part of an Interactive Synthesis Tool for Advanced Robotics (I-

STAR) (see Section 2.1). I-STAR was further comprised of a three major sub-

systems. These were a mechanical module selection system (MCAD), a software

module selection system (SCAD), and a controller module selection system

(CCAD). In the original concept of I-STAR, MCAD, SCAD, and CCAD were

equally important. This research has however tilted the balance towards SCAD.

The primary reasons for SCAD becoming a more complex system that requires

substantial development efforts are:

• System controller technology will achieve standardization and will become

available as a collection of low-cost personal computers that can be assembled

on demand. Also, the granularity of the assembled systems will be somewhat

higher. For example, earlier systems were based on tight-coupling of multiple

processors. This might change to a distributed computing environment that is

comprised of multiple personal computers that are connected using high-

speed communication links. Due to these changes, the importance of CCAD

has considerably decreased.

• The actuator (or mechanical components) will be much more complex than

perceived in I-STAR. However, there will be fewer different types of

actuators but will be much more standardized (both in their interfaces and in

their models). As a consequence, the collection of standard modules

necessary to create a very large population of systems will go down



363

considerably8. Hence, the emphasis in I-STAR for their selection is

diminished.

• What has happened, however, is that the complexity and required generality

of object-oriented software (therefore OSCAR and its future generations) has

expanded dramatically. For example, a single mechanical module (an

actuator) may now need more than 30 different software modules to fully

extract its functionality. This will lead to an increase in the importance of the

SCAD selection process that was envisioned in I-STAR. This is significant

for manufacturing cell development. Software modules are now required to

adhere to strict standards and should exhibit reuse via generality and

extensibility. This research is a step towards this goal.

7.4.6.2. Desired Software Functionality for Cell Operation

The development of manufacturing cell technology is the ultimate goal of

the Robotics Research Group. This research has led to the development of

software components that will be instrumental in the development of a

manufacturing cell. However, not all software areas that are required for

manufacturing cell development have been addressed. These are listed in Table

7.13. It should be noted that some of the issues listed in Table 7.13 were

addressed by OSCAR. The issues that were not addressed will also draw upon

the functionality provided by OSCAR.

8 A result of extensive discussions with D. Tesar in August of 1996.



364

7.5. Timeline for Future WorkThis section discusses a time-line for future development of OSCAR and

other software related technologies. The final goal is the development of a

Cell Software Areas Functionality

System Parameters⇒

Actual link, actuator, tool, etc. parameters frommetrology⇒ Automatic download of as built parameters

Self-Referencing ⇒ Automatic procedure to boot-up system for fullcalibration and referencing

Tool-Management ⇒ Warehouse of tools with a data-base of properties⇒ Criteria-based selection system to match physical

operations performed by cell

Sensor Management ⇒ Array of sensors to calibrate cell, monitor celloperation, or to measure/qualify products

⇒ Fully integrated into cell operation

Configuration Management⇒

Best selection of actuator resources (40+) in thephysical configuration best suited to perform agiven task

Software Management ⇒ 1000’s of software modules for cell operation⇒ Operator supervised selection of software

modules, criteria norms, performance indices, etc.⇒ Need for a “selector’s assistant”

Obstacle Avoidance ⇒ Complex tool, object and robot motions (includingfixtures) managed without interference

Condition-Based Maintenance

⇒ Continuous monitoring of all subsystems⇒ Performance indicators recommend module

maintenance and replacement Archiving ⇒ All process data for product realization stored for

future reference and lessons learned

Operator Intervention ⇒ Performance indices displayed to operator forsystem awareness, and guidance for prioritychange

Table 7.13: Key Software Areas for Manufacturing Cell Development.



365

completely automated manufacturing cell that supports a wide variety of

applications.

Figure 7.8 shows that the OSCAR technology will be completely

developed in the middle of 1998. The other system control technologies will also

reach their full development by 1999. The preliminary development of

manufacturing cell technology has already been done. Manufacturing cells

complete in all aspects but fully developed condition-based maintenance will be

operational by the year 2001. An advanced actuator control software architecture

would also be in place by the year 2000.

T e c h n o l o g y a n d C o m p l e t e n e s s L e v e l

Time (years)

OSCAR SCAD

Real-TimeControl

Man-Machine

Interface

Man-MachineInterface

Actuator ControlSoftware

Actuator ControlSoftware

ManufacturingCells

1 2 3 4 5

Man-MachineInterface

ManufacturingCells

ManufacturingCells

ManufacturingCells

Condition-BasedMaintenance

Condition-BasedMaintenance

Condition-Based

Maintenance

OSCARReal-Time

ControlActuator Control

Software

Figure 7.8: Time-line for Future Work.



369

Appendix A

A. Software Development Guidelines

This document proposes a software design and development philosophy

for current and future software development at the Robotics Research Group.

First the design philosophy is discussed. Then a synopsis of the design process is

given. After that, some programming guidelines are stated and some sample code

is listed.

A.1. Software Design Philosophy

All mature industries, like the automobile industry, are characterized by

the presence of a component’s industry. For example, an automobile is made up

of components that are supplied from different vendors. Currently there is a

revolution taking place in the commercial software industry. This has been

brought on by the popularity of object-oriented design. A similar revolution is

desired in the intelligent machine's software industry. This can be achieved by

stressing the development of software modules (henceforth called components)

which have the following characteristics:• Standardized Interfaces,

• Completeness and abstractness (should have a black box appearance),

• Reusability, and



370

• Portability.

For a long time, software development was directed towards fulfillingproject goals. This often led to the development of shoddy software that had little

reuse potential. This made future releases harder and more expensive. Emerging

software design philosophies stress the development of robust components that

can be modified and assembled to achieve project goals. Keeping this paradigm

shift in mind, the software design philosophy of the Robotics Research Group can

be summed up in one line:

“From Projects to Components.”

A.2. How do we achieve our design goals?

One means of achieving our design goal of building reusable components

is to develop software using object-oriented programming. Object-oriented

programming has four key components. These are:

• Information hiding,

• Data abstraction,

• Dynamic binding, and

• Inheritance.

Classes, a key component of object-oriented programming (in C++)

provide all the information necessary to construct and use objects of a particular

type. A class here is analogues to a template from which instances (objects) can

be created. Each instance has a state associated with it.

Information hiding is achieved by hiding the inner working details of a

class. This helps in avoiding inter-dependencies between components and also

makes modification easier.



371

Data-abstraction is used to abstract the functionality of a class and give it a

black-box look and feel.

Dynamic binding is used for dynamic polymorphism and to avoid the use

of switch statements to determine the type of an object (e.g., which class was it

instantiated from).

Inheritance provides us a means of sub-classing. It allows for creation of

new classes by specifying the differences between the new class and an existing

class. This promotes reusability (see section 2.5 for details on software design).

Another issue to consider in the design and specification of components is

the types of reuse desired from the components. Components can offer reuse in

two forms: generality and extensibility. An example of generality are the first

generation of Macintosh computers. These Macintoshes were general enough to

run different software but were not extensible. That is, you could not make

hardware modifications like adding RAM. Our goal is to exploit reuse through

generality and extensibility. To achieve this kind of reuse, a solid set of

methods and techniques is desired.

A.3. The Design Process

This section gives a brief outline of traditional engineering software

design and object-oriented software design as specified by Booch [1994]. This

information is compiled from books on engineering design and software design.

An interesting thing to note is that none of the software design books reference

the work done in the area of engineering design in the earlier part of this century.

This is perplexing, as these books contain a wealth of design information that is

applicable to all systems.



372

A.4. Traditional Engineering Design

A.4.1. What is Design?

As defined by Pahl and Beitz [1988], “Designing is an intellectual attempt

to meet demands in the best possible way. A systematic design alone can produce

rational solutions.”

A.4.2. What are the qualities of a good designer?

• Initiative,

• Resolution,

• Economic Insight,

• Tenacity,

• Optimism,

• Sociability, and

• Teamwork.

A.4.3. Summary of the Design Process

1. Task clarification,

2. Conceptual design,

3. Embodiment design, and

a) Layout design

b) Form design

4. Detail design.

All throughout the design process one should have:⇒ the required motivation,

⇒ clarify the boundary conditions,

⇒ dispel prejudice,



373

⇒ look for variants,

⇒

make decisions, and⇒ balance between an intuitive approach and a systematic approach.

A.4.4. Critical Path Analysis

A critical path analysis allows designers to manage time for

⇒ feasibility study,

⇒ search for solutions, and

⇒ evaluation of results.

A.5. Software Design Process

There are three steps in object-oriented software development as specified

by Booch [1994] [White]. These are outlined in the following sections:

A.5.1. Requirement Analysis

The objectives of requirements analysis are:

• To find out what customers want the system to do, and

• to form a contract between the customer and the developer.

The deliverables of the requirement analysis are:

• System Charter: This outlines the responsibilities of the system.

• System Function Statement: This outlines the key use cases of the system.

A.5.2. Domain Analysis

The objectives of domain analysis are:• Add appropriate level of abstraction to a system.

• Identify all major objects in the domain including all data and major

operations.



374

The deliverables of domain analysis are:

•

Class diagrams that identify the key classes, or types, of the domain.• Class specification, which contain all semantic definitions of the classes, their

relationships, their attributes, and their key operations.

• Object-scenario diagrams, which illustrate how the objects will interact to

carry out key system functions.

• Data dictionary, which lists all domain entities including classes,

relationships, and attributes.

The steps involved in domain analysis are:

• define Classes,

• define relationships,

• define operations,

• find attributes (properties that describe that class),

• define inheritance, and

• validate and iterate.

A.5.3. System Design

The objectives of system design are:

• Determine effective, efficient, and cost-effective implementation to carry out

the function.

• To map ideal or logical analysis developed during domain analysis to objects

and classes that can be coded.

The deliverables of system design are:

• Architectural description, that is, hardware, CPU, OS, language, etc.

• Executable release descriptions.



375

• Class-category diagrams, which model the partitioning of the system into

high-level groups.• Design class diagrams, which show detail data types and structures, etc.

• Design object-scenario diagrams, which show detail operational logic.

• New specifications supporting these diagrams.

• Amended class specifications showing full operational specifications for those

operations with complex algorithms (very valid in robotic software).

The steps involved in system design are:

•

determine initial architecture,• plan executable releases,

• develop executable releases,

• refine the design.

This section gave a brief overview of the iterative process of object-

oriented analysis and design. As a class is a key component of object-oriented

software, meaningful names should be used for them. Ill defined names simply

imply ill-defined abstractions. Also, a good class has loose or weak coupling and

does not have many relationships to other classes outside its supertypes or

subtypes. For more details on the process of object-oriented software design refer

to Booch [1994].

A.6. Programming Guidelines

1. The programming guidelines outlined here fall into three general categories.

These author was exposed to these guidelines while working at National

Instruments. The details of these guidelines are listed in Kapoor [1995] and

an example application of these guidelines is given in the next section.



376

A.7. Example

A.7.1. File Vector.hpp

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // Title : Vector.hpp // Project : D&D // Created : 09/19/95 @ 23:35:30 Central Standard Time // Author : Chetan Kapoor // Platforms : All // Copyright : The University of Texas at Austin 1995. All Rights Reserved. // Access : Company Confidential // Purpose : This file implements the class declaration for an RRVector class

//-------------------------------------------------------------------------------------------------------------------------- // // Classes: // RRVector // // Global Functions: // <none> // // Global Variables: // <none> // //-------------------------------------------------------------------------------------------------------------------------- // // $Revision$ 1.0 // // $Log$ // New file created (19th September, 95) ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// #if !defined(Vector_hpp)#define Vector_hpp

//+====================================================================== // Includes //=======================================================================

#include <RRCommon.hpp>

#include <iostream.h>

//====================================================================== // Class declaration for RRVector begins //=======================================================================

class RRVector{

public:RRVector(unsigned int, double* elements = 0);



377

RRVector(const RRVector&);~RRVector();

void Grow(unsigned int);double& operator=(unsigned int);unsigned int GetSize();

protected:unsigned int size;double elements;RRVector();initialize(unsigned int, double* = 0);

private:

};

//====================================================================== // Include inline function file //=======================================================================

#include “RRVector.ipp”

#endif // #if !defined....



378

A.7.2. File Vector.ipp

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // Title : Vector.ipp // Project : D&D // Created : 09/19/95 @ 23:50:30 Central Standard Time // Author : Chetan Kapoor // Platforms : All // Copyright : The University of Texas at Austin 1995. All Rights Reserved. // Access : Company Confidential // Purpose : This file defines the inline functions for the RRVector class //-------------------------------------------------------------------------------------------------------------------------- // // Classes: // RRVector

// // Global Functions: // <none> // // Global Variables: // <none> // //-------------------------------------------------------------------------------------------------------------------------- // // $Revision$ 1.0 // // $Log$ // New file created (19th September, 95) /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - RRVector // // Description: // This is the constructor for the RRVector class // // Parameters: // _sz - Size of the RRVector to create. Should be greater than 0. // _elements - an array of doubles which initializes the RRVector. If no value // specified the elements default to zero/ // Return Value: // Does not return anything

// // Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

inline RRVector::RRVector(unsigned int _sz, double* _elements )



379

{initialize(_sz, _elements);

}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - RRVector // // Description: // This is the const reference constructor (or copy constructor)for // the RRVector class // // Parameters: // _rrv - An RRVector from which the new RRVector is created // // Return Value: // Does not return anything

// // Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

inline RRVector::RRVector(const RRVector& _rrv){

initialize(_rrv.size, _rrv.elements);}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - RRVector //

// Description: // This is a protected constructor which is used by derived classes to bypass the // the use of the public constructors of this class. This constructor does nothing // but set elements = 0; // // Parameters: // none // // Return Value: // Does not return anything // // Exceptions: // none //

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

inline RRVector::RRVector(){

elements = 0;}

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



380

// // FunctionName - ~RRVector //

// Description: // This is the destructor for the RRVector class // // Parameters: // none // // Return Value: // Does not return anything // // Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

inline RRVector::~RRVector(){if(elements)

delete [] elements;}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - GetSize // // Description: // This function gets the size of a particular RRVector object // // Parameters: // none

// // Return Value: // Returns the size of the RRVector object // // Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

inline unsigned int RRVector::GetSize(){

return size;}



381

A.7.3. File Vector.cpp

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // Title : Vector.cpp // Project : D&D // Created : 09/19/95 @ 00:20:30 Central Standard Time // Author : Chetan Kapoor // Platforms : All // Copyright : The University of Texas at Austin 1995. All Rights Reserved. // Access : Company Confidential // Purpose : This file defines the functions for the RRVector class //-------------------------------------------------------------------------------------------------------------------------- // // Classes: // RRVector

// // Global Functions: // <none> // // Global Variables: // <none> // //-------------------------------------------------------------------------------------------------------------------------- // // $Revision$ 1.0 // // $Log$ // New file created (19th September, 95) /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - Grow // // Description: // This function is used to change the size of an RRVector object // // Parameters: // _sz - The new size of the RRVector. S hould be greater than 0. // // Return Value: // Does not return anything //

// Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

void RRVector::Grow(unsigned int _sz ){



382

double *old_element = element;int oldSize = size;

size = _sz;element = new double[size];for(int i = 0; i < oldSize; i++)

element[i] = old_element[i];

delete [] old_element;}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - initialize // // Description: // This is the const reference constructor (or copy constructor)for

// the RRVector class // // Parameters: // rrv - An RRVector from which the new RRVector is created // // Return Value: // Does not return anything // // Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

void RRVector::initialize(unsigned int _sz, double* _array){

size = _size;elements = new double[size];if(_array){

for(int j = 0; j < size; j++){elements[j] = _array[j];

}}

}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // // FunctionName - operator[unsigned int] // // Description:

// This is an operator overload method for accessing and setting individual // elements of an RRVector // // Parameters: // _element: The element to set // // Return Value: // returns a reference to the element which is being set.



383

// // Exceptions: // none

// ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

double& RRVector::operator(unsigned int _elementNumber){

if(_elementNumber > size){DisplayError(“Index out of range for RRVector::operator[int]”);abort();

}return elements[_elementNumber]

}

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// //

// FunctionName - operator= // // Description: // This function implements the assignment operator // // Parameters: // _rrv: The RRVector object from which to assign // // Return Value: // Returns a reference to the RRVector object // // Exceptions: // none // ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

RRVector& RRVector::operator=(const RRVector& _rrv){

//---------------------------------------------------------------------------------------------------------------------- // Check for assignment to itself //----------------------------------------------------------------------------------------------------------------------

if(this != &_rrv){delete [] elements;initialize(_rrv.size, _rrv.elements);

}return *this;

}



384

Appendix B

B. OSCAR Class Library Reference

B.1. Base Abstractions

B.1.1. class RRBase

#include <Base/Base.hpp>

Public Methods

RRBase(const RRString& name = RRString(" "));

Constructor for the RRBase class.Takes as argument the name of theobject. This class acts as the baseclass for all other classes.Functionality for synchronizationin multi-threaded environmentscan be added over here.

Arguments:

name Specifies the name of the object as aRRString.

RRBase(const RRBase& rb);

Copy constructor for the RRBaseclass.

Arguments:

rb Specifies the name of the RRBaseobject to be copy constructed.

const RRString& GetName() const;

Accessor method for querying the

name of the object.

Return Value: Returns the name of the

object.void SetName(const RRString& name);

Method for setting the name of theobject.

Arguments:name Specifies the name of the object as a

RRString.

RRBase& operator=(const RRBase& rb);



385

Operator overload for copying anRRBase object.

Arguments:rb Specifies the object to be copied.

Return Value: Returns a reference to itself.



386

B.2. Mathematical Abstractions

B.2.1. class RRVector : public RRBase

#include <Math/Vector.hpp>

Public Methods

RRVector(int sz, const double* array = 0);

Constructor for the RRVectorclass. Takes as argument thename of the object. RRVector isused to store an array of doubles.

Arguments:sz Specifies the size of the vector.

array A pointer to an array of doubles that isused to initialize the vector object. If

this is null, all elements of the vectordefault to 0.0.

RRVector(const RRVector& v);

Copy constructor. Arguments:v Specifies the name of the object to be

copy constructed.

~RRVector();

Destructor for deallocation of memory.

void SetValues(double* array) const;

Method for setting the values of the vector.

Arguments:array Specifies the name of the array from

which the elements of the vector are set.This should have the same number of elements as the calling object.

const double* GetArray() const;

Method for accessing theinternally stored array of doubles. Should be carefullyused as this method breaks theencapsulation.

Return Value: A pointer to the array of doublescontained inside the object.

double GetMagnitude() const;

Method for accessing the norm

of the vector. This basicallycomputes the square root of thesum of the squares of theelements.

Return Value: The norm of the vector.

double GetMagnitude(int fromIndex, int toIndex) const;



387

Method for computing the normof a selected set of elements

from the vector.

Arguments: fromIndex: The index of the starting element

from which the norm is to becomputed.

toIndex: The index of the last element tillwhich the norm is to becomputed.

Return Value: The norm of the desired sectionof the vector.

int GetSize() const;

Method for accessing the size of the vector.

Return Value: The size of the vector.

void Grow(int growth);

Method for increasing the size of

the vector, that is, making itgrow.

Arguments:

growth: The amount by which the vectorshould grow.

int Output(ostream& out = cout) const;

Method for outputting the vectorto a stream.

Arguments:

out: The output stream object on which thevector is to be outputted.

Return Value: returns 1.

int Input(istream& in = cin);

Method for inputting the vectorfrom a stream.

Arguments:

in: The input stream object from which thevector is to be inputted.

Return Value: returns 1.double& at(int index) const;

Method for accessing and settingindividual elements of thevector. No range checking isperformed in this method.

Arguments:index: Index of the element to be accessed or to

be set.Return Value: returns a reference to the index

element.

double& operator[](int index) const;

Operator overload for accessingand setting individual elementsof the vector. Range checking isperformed in this method.

Arguments:

index: Index of the element to be accessed or tobe set.

Return Value: returns a reference to the index

element.RRVector& operator=(double value);



388

Operator overload for ‘=’ forsetting all the elements of a

vector to a particular number.

Arguments:value: Number to which all the elements of the

vector should be set.Return Value: returns a reference to the vector

being set.

int operator==(const RRVector& v) const;

Comparison method. Arguments:

v: RRVector with which the comparison isto be made.

Return Value: Returns 1 if equal and 0 if not.

RRVector operator*(double number);

Method to multiply an RRVectorwith a double.

Arguments:number: The number with which all the

elements of the RRVector are to

be multiplied.Return Value: The resulting RRVector.

RRVector& operator*=(double number);

Method to multiply all itselements with a double.

Arguments:

number: The number with which all theelements of the RRVector are tobe multiplied.

Return Value: Returns a reference to self.

RRVector& operator+=(double number);

Method to add a double to all itselements.

Arguments:number: The number which has to be

added to all the elements.Return Value: Returns a reference to self.

RRVector& operator/=(double number);

Method to divide all its elementswith a double.

Arguments:

number: The number with which all theelements of the RRVector are tobe divided.

Return Value: Returns a reference to self.

RRVector& operator-=(double number);

Method to subtract a doublefrom all its elements.

Arguments:number: The number which has to be

subtracted from all the elements.

Return Value: Returns a reference to self.RRVector& operator+=(const RRVector& v);

Method to add anotherRRVector to self.

Arguments:v: The RRVector that has to be added.Return Value: Returns a reference to self.

RRVector& operator-=(const RRVector& v);



389

Method to subtract anotherRRVector from self.

Arguments:v: The RRVector that has to be subtracted.

Return Value: Returns a reference to self.RRVector& operator=(const RRVector& v);

Method to copy anotherRRVector to self.

Arguments:

v: The RRVector to be copied.Return Value: Returns a reference to self.

Protected Methods

void init(int size, const double* array);

Method to allocate memory andto initialize the vector. Thismethod is called by theconstructors.

Arguments:size Specifies the size of the vector.

array A pointer to an array of doubles that isused to initialize the vector object. If this is null, all elements of the vector

default to 0.0.

RRVector();

Protected constructor that is tobe used by derived classes thatdo their own memorymanagement. This constructoris a place holder and doesnothing.

Other Related Functionality

extern RRVector operator+(const RRVector& a, const RRVector& b);

Function for adding two

RRVector’s.

Arguments:

a Vector to be added to.b Vector to be added.Return Value: The resulting vector, i.e., a + b

extern RRVector operator-(const RRVector&, const RRVector&);

Function for subtracting twoRRVector’s.

Arguments:

a Vector to be subtracted from.b Vector to be subtracted.Return Value: The resulting vector, i.e., a - b

extern RRVector operator*(const RRMatrix& m, const RRVector& v);

Function for multiplying anRRMatrix with an RRVector.The RRMatrix size should be

size X 1, where size is the size of the RRVector.

Arguments:

m Matrix with which the vector is to bemultiplied.

v Vector to be multiplied.Return Value: The resulting vector, i.e., m * v

extern ostream& operator<<(ostream& strm, const RRVector& v);



390

Operator overload for ‘<<.’Outputs the vector to an output

stream and encloses the outputwithin square brackets.

Arguments:strm Output stream.

v Vector to be outputted.Return Value: Reference to the output stream.

inline istream& operator>>(istream& is, RRVector& a);

Operator overload for ‘>>.’Inputs the vector from an inputstream.

Arguments:strm Input stream.

v Vector to hold the input.Return Value: Reference to the input stream.

extern RRVector GetRow(int row, const RRMatrix& m);

Function for extracting aparticular row from anRRMatrix object and returning itas an RRVector.

Arguments:

row Row to be extracted from m.

m Matrix from which the row has to beextracted.

Return Value: Extracted row.extern RRVector GetCol(int col, const RRMatrix& m);

Function for extracting aparticular column from anRRMatrix object and returning itas an RRVector.

Arguments:col Column to be extracted from m.

m Matrix from which the column has to beextracted.

Return Value: Extracted column.

extern void GetRow(RRVector& result, int row, const RRMatrix& m);

Function for extracting aparticular row from anRRMatrix object. This is a

faster means of accessing rowsof a matrix when this function iscalled repeatedly. This functionstores the extracted row in its

result argument and thus saveson an internal constructor call toRRVector.

Arguments:

result RRVector in which the extracted rowhas to be stored.

row Row to be extracted from m.m Matrix from which the row has to be

extracted.

extern void GetCol(RRVector& result, int row, const RRMatrix& m);



391

Function for extracting aparticular column from an

RRMatrix object. This is afaster means of accessingcolumns of a matrix when thisfunction is called repeatedly.This function stores theextracted column in its result

argument and thus saves on aninternal constructor call toRRVector.

Arguments:result RRVector in which the extracted column

has to be stored.row Column to be extracted from m.

m Matrix from which the column has to beextracted.



392

B.2.2. Class RRVector3 : public RRVector

#include <Math/Vector3.hpp>

Public Methods

RRVector3();

Constructor. Creates an RRVector3and initializes all elements to 0.0.

RRVector3(double x, double y, double z);

Constructor. Creates an RRVector3. Arguments: x Sets element 0 to this value.

y Sets element 1 to this value. z Sets element 2 to this value

RRVector3(double *array);Constructor. Creates an RRVector3. Arguments:

array An array of doubles of size threethat is used to initialize theelements of RRVector3.

RRVector3(double a);

Constructor. Creates an RRVector3. Arguments:

a Initializes all elements of RRVector3 to a.

RRVector3(const RRVector3& V);

Copy constructor. Creates anRRVector3.

Arguments:V Initializes all elements by the

elements of V.RRVector3(const RRVector& V);

Copy constructor. Creates anRRVector3. The input argument V

should be of size three.

Arguments:

V Initializes all elements by theelements of V.

~RRVector3();

Destructor.

double& X();

Access or set element 0. Return Value: Returns a reference to the0 element.

double& Y();

Access or set element 1. Return Value: Returns a reference to theelement 1.

double& Z();

Access or set element 2. Return Value: Returns a reference to theelement 2.

void X(double x_val);



393

Set element 0. Arguments:

x_val: Sets element 0 to this value.

void Y(double y_val);Set element 1. Arguments:

y_val: Sets element 1 to this value.

void Z(double z_val);

Set element 2. Arguments: z_val: Sets element 2 to this value.

RRVector3 Unit(void) const;

Unitizes an RRVector3. Return Value: The unitized vector.

RRVector3 Cross(const RRVector3& v) const;

Computes the cross-product withanother RRVector3.

Arguments:

v: The RRVector3 with which thecross product is to be computed.

Return Value: The cross product.

double Dot(const RRVector3& v) const;

Computes the dot-product withanother RRVector3.

Arguments:v: The RRVector3 with which the

dot product is to be computed.Return Value: The dot product.

double Norm(void) const;

Computes the norm of theRRVector3.

Return Value: The norm of the callingRRVector3.

RRVector3& Normalize(void);

Normalizes the calling object. That is

divides each element with the normand returns the result.

Return Value: The normalized vector.

double Min(void) const;

Finds the minimum element. Return Value: The minimum of the threeelements.

double Max(void) const;

Finds the maximum element. Return Value: The maximum of the threeelements.

RRVector3 operator-(void) const;

Computes and returns thecomplement.

Return Value: Complement.

RRVector3 operator/(double a) const;Divides all elements by a double andreturns the result.

Arguments:a The number to divide by.Return Value: The resulting RRVector3.

RRVector3 operator*(double a) const;



394

Multiplies all elements by a doubleand returns the result.

a The number to multiply by.Return Value: The resulting RRVector3.

RRVector3& operator=(const RRVector3& v);Copies one RRVector3 into another. v The object to copy.

Return Value: The resulting RRVector3.

Protected Methods

void init(int sz, const double* array = 0);

This method is redefined in this class.Over here no memory allocation onthe heap takes place. This is unlikethe parent class. This methodinitializes the elements with thecontents of the array array.

Arguments:sz The size of the RRVector, in this

case it is three.array An array of doubles that is used to

initialize the elements.

Other Related Functions

inline RRVector3 Normal(const RRVector3& v1, const RRVector3& v2);

Function to compute the normal of two three dimensional vectors. v1 iscrossed with v2 to compute thenormal.

Arguments:v1 The first vector in the set.

v2 The second vector in the set.Return Value: The normal of v1 and v2.

inline RRVector3 UnitNormal(const RRVector3& v1, const RRVector3& v2);

Function to compute the unit normalof two three dimensional vectors. v1

is crossed with v2 to compute thenormal.

Arguments:v1 The first vector in the set.

v2 The second vector in the set.Return Value: The unit normal.



395

B.2.3. Class RRHandPose : public RRVector

#include <Math/HandPose.hpp>

Public Members:

enum ORIENT_TYPE {EULER_XYZ, EULER_ZYZ, FIXED_XYZ};

Enumeration defined to represent theorientation of the RRHandPosevector. All the twelve fixed andEuler angle sets can be added.

EULER_XYZ : XYZ Euler angles.

EULER_ZYZ : ZYZ Euler angles.FIXED_XYZ : XYZ Fixed angles.

Public Methods:

RRHandPose(ORIENT_TYPE type = FIXED_XYZ);

Constructor. Creates an RRHandPose

vector with all the six elements zeroand the default orientation typeFIXED_XYZ.

Arguments:

type: Specifies the orientation type.

RRHandPose(double x, double y, double z, double R, double P, double Y,ORIENT_TYPE type = FIXED_XYZ);

Constructor. Creates an RRHandPosevector with the six elements set to x,

y, z, R, P, Y , and the defaultorientation type FIXED_XYZ.

Arguments: x: X position.

y: Y position. z: Z position.

R: First orientation angle in radians.P: Second orientation angle in radians.

Y : Third orientation angle in radians.

type: Specifies the orientation type.RRHandPose(double *array, ORIENT_TYPE type = FIXED_XYZ);

Constructor. Creates an RRHandPosevector with its six elements initializedfrom the array array, and the defaultorientation type FIXED_XYZ.

Arguments:array: Array of doubles of size six.

type: Specifies the orientation type.

RRHandPose(const RRHandPose& V);

Destructor. Creates an RRHandPoseand initializes it with contents andorientation type of V .

Arguments:V : RRHandPose vector that has to be

copied.

~RRHandPose();

Destructor.double& X();

Accesses or sets the first element. Return Value: A reference to the firstelement.

double& Y();



396

Accesses or sets the second element. Return Value: A reference to the secondelement.

double& Z();Accesses or sets the third element. Return Value: A reference to the third

element.

double& Roll();

Accesses or sets the fourth element. Return Value: A reference to the fourthelement.

double& Pitch();

Accesses or sets the fifth element. Return Value: A reference to the fifthelement.

double& Yaw();

Accesses or sets the sixth element. Return Value: A reference to the sixthelement.

RRVector3 GetPosition() const;

Accesses the position sub-set of theRRHandPose.

Return Value: An RRVector3 that storesthe position of theRRHandPose.

void GetPosition(RRVector3& p) const;

Accesses the position sub-set of theRRHandPose.

Arguments: p: An RRVector3 that stores the

position sub-set of theRRHandPose.

RRVector3 GetOrientation() const;

Accesses the orientation sub-set of

the RRHandPose.

Return Value: An RRVector3 that stores

the orientation of theRRHandPose.

void GetOrientation(RRVector3& o) const;

Accesses the orientation sub-set of the RRHandPose.

Arguments:o: An RRVector3 that stores the

orientation of the RRHandPose.

ORIENT_TYPE GetOrientationType(void) const;

Accesses the orientation type. Couldbe any of the ORIENT_TYPEenumeration.

Return Value: The orientation type.

void SetOrientationType(ORIENT_TYPE oType);

Sets the orientation type to any one of the ORIENT_TYPE enumeration’s.

Arguments:oType: The desired orientation type.

RRXform ToTransform(void) const;



397

This method converts anRRHandPose into its equivalent 4 X 4

representation. The orientation typeof the RRHandPose vector is takeninto account to do the conversion.This method internally creates anRRXform and returns the convertedresults in it.

void ToTransform(RRXform& xf) const;

This method converts anRRHandPose into its equivalent 4 X 4representation. The orientation typeof the RRHandPose vector is takeninto account to do the conversion.

This method stores the result in xf .This method should be used insituations where it is calledrepeatedly inside a loop.

Arguments: xf The 4 X 4 matrix in which the

converted RRHandPose is stored.

int Subtract(const RRHandPose& with, RRHandPose& result) const;

This method implements a moreefficient means of subtracting twoRRHandPose vectors. The benefitsof this method are realized when it iscalled repeatedly inside a loop. Thisis because no temporary variables arecreated inside this method.

Arguments:

with: The vector which has to besubtracted.

result: The result of the subtraction. Thatis, result = this - with.

Return Value: 1

RRHandPose operator-(const RRHandPose& rh) const;

Subtraction operator. Arguments:rh: Vector to be subtracted.Return Value: The result of the

subtraction. Thatis this - rh.

RRHandPose& operator=(const RRHandPose& rh);

Assignment operator. Arguments:rh: Vector to be assigned.Return Value: The resulting vector.

RRHandPose& operator=(const RRVector& v);

Assignment operator. Arguments:v: Vector to be assigned. Should be

of size six.Return Value: The resulting vector.

Protected Methods:

void init(int sz, const double* array = 0);



398

This method is redefined in this class.Over here no memory allocation on

the heap takes place. This is unlikethe parent class. This methodinitializes the elements with thecontents of the array array.

Arguments:

sz The size of the RRHandPose. In

this case it is six.array An array of doubles of size six that

is used to initialize the elements.

void eulerXYZToTransform(RRXform& hand) const;

This method is used to convert anRRHandPose with orientation typeEULER_XYZ to its RRXformrepresentation.

Arguments:hand The RRXform in which the

converted RRXform is stored.

void eulerZYZToTransform(RRXform& hand) const;

This method is used to convert anRRHandPose with orientation type

EULER_ZYZ to its RRXformrepresentation.



void fixedXYZToTransform(RRXform& hand) const;

This method is used to convert anRRHandPose with orientation typeFIXED_XYZ to its RRXformrepresentation.





399

B.2.4. Class RRMatrix : public RRBase

#include <Math/Matrix.hpp>

Public Methods

RRMatrix(int nr, int nc, double* array = 0, const RRString& name = RRString(" "));

Constructor. Constructs a matrix of size nr X nc and initializes it with

array.

Arguments:nr: Number of rows.

Nc: Number of columns.array Array of doubles used to initialize

the matrix. Should be of size(nr * nc). If null, all elements areinitialized to 0.0.

name Name of the object.

RRMatrix(const RRMatrix& m);

Copy constructor. Arguments:m: Matrix to be used for initialization.

RRMatrix(const RRMatrixRow& mr);

Copy constructor. Creates a matrixand initializes it with the elements of

mr .

Arguments:

mr: Matrix row to be used forinitialization.

RRMatrix(const RRMatrixCol& mc);

Copy constructor. Creates a matrixand initializes it with the elements of

mc.

Arguments:mc: Matrix column to be used for

initialization.

RRMatrix(int size, double* array, const RRString& name = RRString(" "));Constructor. Constructs a squarematrix of size size X size andinitializes it with array.

Arguments:

size: Size of the square matrix.array Array of doubles used to initialize

the matrix. Should be of size(nr * nc). If null, all elements areinitialized to 0.0.


RRMatrix(int size, diagonal diagValue, const RRString& name = RRString(" "));

Constructor. Constructs a diagonalmatrix of size size X size andinitializes its diagonal elements withdiagValue.

Arguments:size: Size of the diagonal square matrix.

diagValue: A double specifying thevalue of the diagonalelements.


~RRMatrix();

Destructor. Deallocates memory

double& at(int irow, int icol) const;



400

Used for accessing or setting the

irow, icol element. No range

checking is performed in this method.

Arguments:

irow: Row position of the element.

icol: Column position of the element.Return Value: A reference to the element

at irow and icol.

double& operator()(int irow, int icol) const;

Operator overload for accessing orsetting the irow, icol element. Rangechecking is performed in this method.

Arguments:

irow: Row position of the element.icol: Column position of the element.Return Value: A reference to the element

at irow and icol.

RRMatrixRow row(int rowNo) const;

Method for accessing a row. Thereturned object maintains a reference

to the calling object. Hence anychanges to the returned object reflecton the calling object.

Arguments:rowNo: Row to access.

RRMatrixCol col(int colNo) const;

Method for accessing a column. Thereturned object maintains a referenceto the calling object. Hence anychanges to the returned object reflecton the calling object.

Arguments:

colNo: Column to access.

int isSquare() const;

Test whether a matrix is square. Return Value: 1 if matrix is square.

0 if matrix in non-square.

int sameSize(int nrow, int ncol) const;

Method for comparing the size of thematrix.

Arguments:nrow: Number of rows to compare with.

ncol: Number of columns to comparewith.

Return Value: 1 if same size.0 if not same size.

int nRow() const;

Get the number of rows. Return Value: Number of rows.

int nCol() const;

Get the number of columns. Return Value: Number of columns.RRMatrix& operator=(const RRMatrix& m);

Copy operator. Copies all elementsand is valid only for same sizematrices.

int operator==(const RRMatrix&) const;



401

Comparison operator. Return Value: 1 if same size and allelements are the same.

0 if otherwise.RRMatrix t() const;

Transpose of a matrix. Return Value: Returns the transpose.

void t(RRMatrix& m) const;

Transpose of a matrix. This methodis more efficient when called inside aloop repeatedly. This is because notemporary matrix is created internallyto this method.

Arguments:m Matrix in which the transpose is

stored.

Void operator*=(double a);

Multiplies all elements of the matrixby a.

Arguments:

a Number to multiply all elements

with.

double Determinant(void) const;

Compute the determinant of thematrix.

Return Value: The determinant.

int LUDecomposition(int* indx, double* d) const;

Lower, Upper triangular de-composition. The calling matrix(*this) is replaced by its LU form.Adopted from Numerical Recipes inC.

Arguments:

indx Holds the output vector whichrecords the row (output)permutation effected by the partialpivoting indx [i...n].

d Is output +-1 depending on whether

the number of row (output)interchanges was even or odd,respectively.

Return Value: 0 if singular1 if non-singular

void LUFowBackSubstitution(const int *indx, double b[]) const;

Forward and Backward substitutionapplied to a matrix. This is generallyapplied to the LU form of a matrix.Adopted from Numerical Recipes inC.

Arguments:indx Holds the input vector returned

from LUDecomposition.b Is input/output.

int Inverse(RRMatrix& inverse) const;

Inverse of a matrix. This methodshould be preferred when calledinside loops.

Arguments:inverse Holds the inverse of the calling

matrix.Return Value: 0 if singular

1 if non-singular-1 if non-square matrix



402

int Inverse(RRMatrix& inverse, double& determinant) const;

Inverse and determinant of a matrix.

This method should be preferredwhen called inside loops.

Arguments:

inverse Holds the inverse of the callingmatrix.

determinant The determinant of thecalling matrix.

Return Value: 0 if singular1 if non-singular-1 if non-square matrix

int SpeedInverse(RRMatrix& inverse, double& determinant) const;

Inverse and determinant of a matrix.This method should be preferredwhen called inside loops and is fasterthan the previous method. However,

this method destroys the callingmatrix.

Arguments:

inverse Holds the inverse of the callingmatrix.

determinant The determinant of the

calling matrix.Return Value: 0 if singular

1 if non-singular-1 if non-square matrix

int SVD(RRMatrix& U, RRVector& V, RRMatrix W) const;

Computes the singular valuedecomposition of the calling matrixwhose size is m X n. Adopted fromNumerical Recipes in C.

Arguments:U matrix of size m X n if m >= n or

matrix of size n X n if m < nV Vector of size n that holds

the Eigen ValuesW matrix of size n X nReturn Value: 0 if no convergence

1 if successful

RRMatrix Inverse() const;

Inverse of a matrix. Return Value: The inverse.

void MultiplyWithTranspose(RRMatrix& result) const;

Multiplies the calling matrix with itstranspose.

Arguments:

result The result of multiplying the callingmatrix with its transpose.

void switchRows(int a, int b);

Switch two rows of a matrix Arguments:

a, b Numbers of the rows to beswitched.

void switchCols(int a, int b);Switch two columns of a matrix Arguments:

a, b Numbers of the columns to beswitched.

void combineRows(int i, double b, int j);



403

Combine two rows of a matrix.row(i) += b*row(j)

Arguments:

i Row to change.

b Factor to multiply with. j Row to be added.

void combineCols(int i, double b, int j);

Combine two columns of a matrix. // col(i) += b*col(j)

Arguments: I Column to change.

b Factor to multiply with. j Column to be added.

RRMatrix operator~() const;

Operator overload for inverting amatrix.

Return Value: The inverse.

double norm() const;

Returns the largest element of the

matrix.

Return Value: The largest element.

RRMatrix operator+(const RRMatrix& m) const;

Operator overload for adding twomatrices.

Arguments:

m Matrix to be added.Return Value: The result of the addition.

RRMatrix operator-(const RRMatrix& m) const;

Operator overload for subtracting twomatrices.

Arguments:m Matrix to be subtracted.Return Value: The result of the subtraction.

RRMatrix operator*(const RRMatrix& m) const;

Operator overload for multiplying

two matrices.

Arguments:

m Matrix to be multiplied.Return Value: The result of the

multiplication.

RRMatrix operator-() const;

Operator overload for negating amatrix.

Return Value: The negative of the callingmatrix.

RRMatrix operator*(double a) const;

Operator overload for multiplying allelements with a double.

Return Value: The resulting matrix.

Protected Methods

RRMatrix(const RRString& name = " ");

Place holder constructor for use byderived classes.

Arguments:name Name of the matrix.

void m_alloc(int rows, int cols);

Method that allocates memory for thematrix.

Arguments:rows Number of rows of the matrix.

cols Number of columns of the matrix.




404

extern void Multiply(const RRMatrix& m, const RRMatrix& n, RRMatrix&result);

Function to multiply two matrices.Should be used over operator*method when matrices are multipliedrepeatedly inside loops. Notemporary objects created inside thismethod.

Arguments:m Matrix to multiply with.n Matrix to multiply with.

result Result of the multiplication.result = m * n.

extern RRMatrix operator*(double a, const RRMatrix& m);

Function to multiply a double with amatrix. Multiplies all elements of thematrix with the double.

Arguments:

a Number to multiply with.m Matrix to multiply with.

result Result of the multiplication.result = m * n.

extern ostream& operator<<(ostream& strm, const RRMatrix& m);Output operator for RRMatrix.



405

B.2.5. Class RRMatrixCol : public RRBase


Public Methods

RRMatrixCol(int colNo, const RRMatrix& m, const RRString& name = " ");

Constructor. The MatrixCol createdholds a reference to the RRMatrix m.

Arguments:colNo Column number of m.

m Matrix whose column is to beaccessed.


RRMatrixCol(const RRMatrixCol& m);

Copy constructor. The created object

will also now hold a reference to theRRMatrix object from which m wascreated.

int nRow() const;

Get number of rows. Return Value: Number of rows.

double& at(int i) const;

Accessing and setting elementswithout range checking.

Arguments:

i Element to access or set.

double& operator()(int i) const;

Accessing and setting elements withrange checking.

Arguments:

i Element to access or set.

RRMatrix Cross(const RRMatrixCol& b);

void operator=(const RRMatrixCol&);

void operator+=(const RRMatrixCol&);


extern ostream& operator<<(ostream& strm, const RRMatrixRow& m);



406

B.2.6. Class RRMatrixCol : public RRBase


Public Methods

RRMatrixRow(int rowNo, const RRMatrix&, const RRString& name = "");

Constructor. The MatrixRow createdholds a reference to the RRMatrix m.

Arguments:rowNo Row number of m.

m Matrix whose row is to be accessed.name Name of the object.

RRMatrixRow(const RRMatrixRow& m);

Copy constructor. The created objectwill also now hold a reference to the

RRMatrix object from which m wascreated.

int nCol() const;

Get number of columns. Return Value: Number of columns.

double& at(int i) const;

Accessing and setting elementswithout range checking.

Arguments:i Element to access or set.

double& operator()(int i) const;

Accessing and setting elements withrange checking.

Arguments:i Element to access or set.

double operator^(const RRMatrixCol&) const; // dot product

void operator=(const RRMatrixRow&);

virtual void printOn(ostream&) const;


extern ostream& operator<<(ostream& strm, const RRMatrixCol& m);



407

B.2.7. Class RRXform : public RRMatrix

#include <Math/Xform.hpp>

Public Methods

RRXform();

Constructor. Creates a 4 X 4 identitymatrix.

RRXform(double f, const RRString& name = RRString(" "));

Constructor. Creates a 4 X 4 matrixwhose diagonal elements are f .

Arguments:

f Diagonal element.name Name of the object.

RRXform(const RRXform& T);

Copy constructor.RRXform(const RRMatrix& T);

Copy constructor. The argument T

should be of size 4 X 4.

~RRXform();

Destructor.

int ToHandPose(RRHandPose& handPose) const;

Method to convert 4 X 4 matrix intoits RRHandPose representation. Thecorrect conversion is applied basedon the ORIENT_TYPE of handPose.

Arguments:

handPose The resulting vectorrepresentation.

Return Value: 1 if no singularity.0 of singularity.

int ToPumaOAT(RRHandPose& end_location) const;

Method to convert 4 X 4 matrix intoits RRHandPose representation thatuses the Puma OAT orientationangles.

Arguments:end_location The resulting vector

representation.Return Value: 1 if no singularity.

0 of singularity.

int ToSingleAxis(RRVector3& axis, double& angle) const;

Method to convert 4 X 4 matrix intoits single axis representation.

Arguments:

axis The resulting single axis thatrepresents the RRXform.

angle The corresponding rotation angle

associated with the single axis.Return Value: 1 if no singularity.

0 of singularity.

RRRot3by3 GetRotationMatrix(void) const;

Accesses the rotation sub-matrix. Return Value: The rotation sub-matrix.

void GetRotationMatrix(RRRot3by3& rrt) const;



408

Accesses the rotation sub-matrix.This method should be used when

accessing the rotation matrixrepeatedly.

rrt The rotation sub-matrix.

void SetRotationMatrix(const RRRot3by3& rrt);

Sets the rotation sub-matrix. rrt The rotation matrix.

RRXform& operator=(const RRXform& T);

Copy operator.

RRXform& operator=(const RRMatrix& T);

Copy operator. Matrix T should beof size 4 X 4.RRXform operator*(const RRXform& m) const;

Multiply operator. This is redefined

over here for computationalefficiency. The last row of thetransformation matrix is assumed tobe [0 0 0 1].

void Multiply(const RRXform& with, RRXform& result) const;

This is faster version of the multiplyoperator. In this method, notemporary objects are createdinternally.

Arguments:

with RRXform with which to multiply.result The result of the multiplication.

result = this * with.

RRXform operator-(const RRXform& m) const;

Operator overload for subtraction.Redefined over here for

computational efficiency.

Arguments:

m RRXform to be subtracted.

Return Value: The result of thesubtraction.

result = this - m.

RRXform operator-() const;

Operator overload for negating anRRXform. Redefined over here forcomputational efficiency.

Return Value: The negative of theRRXform.

void Subtract(const RRXform& with, RRXform& result) const;

A faster method for subtractingRRXform’s. This does not allocateany temporary objects.

Arguments:with RRXform to be subtracted.

result Result of the subtraction.result = this - with.

RRXform& operator-=(const RRXform& m);

Operator overload for subtractionfrom self. Redefined over here forcomputational efficiency.

Arguments:m RRXform to be subtracted.Return Value: The result of the

subtraction.

void InvertXform(RRXform& inverse) const;



409

Method for inversion of a 4 X 4transformation matrix. This is more

efficient than the Inverse methoddefined in the RRMatrix class. Thismethod should be preferred whencalled inside loops.

Arguments:

inverse The Inverse.

RRXform InvertXform(void) const;

Method for inversion of a 4 X 4transformation matrix. This is moreefficient than the Inverse methoddefined in the RRMatrix class. Thismethod allocates a temporary objectinternally and hence is slower.

Return Value: The Inverse.

Protected Methods

void m_alloc(int nrow, int ncol);Method for allocating memory. Thisis redefined over here because theRRMatrix m_alloc method allocatesmemory on the heap and this methodallocates on the stack.

Arguments:nrow Number of rows = 4.

ncol Number of columns = 4.

int toEulerXYZ(RRHandPose& endLocation) const;

Method for converting a 4 X 4homogenous transformation matrixinto an RRHandPose whoseorientation type is Euler XYZ.

Arguments:

endLocation The converted RRXform.Return Value 1 if not singular.

0 if singular.

toEulerZYZ(RRHandPose& endLocation) const;Method for converting a 4 X 4homogenous transformation matrixinto an RRHandPose whoseorientation type is Euler ZYZ.

Arguments:


0 if singular.

int toRPY(RRHandPose& endLocation) const;

Method for converting a 4 X 4homogenous transformation matrixinto an RRHandPose whoseorientation type is Fixed XYZ.

Arguments:


0 if singular.



410

B.2.8. Class RRRot3by3 : public RRMatrix

#include <Math/Rot3by3.hpp>

Public Methods

RRRot3by3();

Constructor. Creates a 3 X 3 matrix.

RRRot3by3(double f, const RRString& name = RRString(" "));

Constructor. Creates a 3 X 3 matrixwhose diagonal elements are f .

Arguments: f Diagonal element.


RRRot3by3(const RRRot3by3& T);

Copy constructor. Copies all the

elements of T into the createdmatrix.RRRot3by3(const RRMatrix& T);

Copy constructor. Copies all the

elements of T into the createdmatrix. Matrix T should be of size

3 X 3.~RRRot3by3();

Destructor.

void ToPumaOAT(RRVector3& endLocation) const;

Converts the 3 X 3 rotation matrix

into the orientation representationsimilar to the one used on Pumarobots.

Arguments:

endLocation The converted form.

void ToEulerXYZ(RRVector3& endLocation) const;

Converts the 3 X 3 rotation matrixinto its Euler XYZ representation.

Arguments:


void ToEulerZYZ(RRVector3& endLocation) const;

Converts the 3 X 3 rotation matrixinto its Euler ZYZ representation.

Arguments:


void ToRPY(RRVector3& endLocation) const;

Converts the 3 X 3 rotation matrixinto its Fixed XYZ representation.

Arguments:


RRVector3 ToRPY(void) const;

Converts the 3 X 3 rotation matrixinto its Fixed XYZ representation andreturns the result.

Return Value: The converted form.

RRRot3by3& operator=(const RRRot3by3& T);



411

Copy operator. Copies all elements. Arguments:

T Object to be copied.

RRRot3by3& operator=(const RRMatrix& T);Copy operator. The argument T

should be of size 3 X 3.Arguments:T Object to be copied.

RRRot3by3 operator*(const RRRot3by3& m) const;

Multiplication operator. Arguments:m Object to be multiplied with.

RRRot3by3 operator*(const RRMatrix& m) const;

Multiplication operator. Matrix m

should be of size 3 X 3.Arguments:m Object to be multiplied with.

void Multiply(const RRRot3by3& with, RRRot3by3& result) const;

Multiplication method. Notemporaries created in this methodand hence is faster.

Arguments:

with Object to be multiplied with.result Result of the multiplication.


void Multiply(const RRMatrix& with, RRRot3by3& result) const;

Multiplication method. Notemporaries created in this methodand hence is faster. Matrix with

should be of size 3 X 3.

Arguments:



void Multiply(const RRVector3& with, RRVector3& result) const;

Multiply an RRRot3by3 with anRRVector3. No temporaries createdin this method and hence is faster.

Arguments:


result = this * with.RRRot3by3 t(void) const;

void Multiply(const RRVector3& with, RRVector3& result) const;

Multiply an RRRot3by3 with a tRRVector3. No temporaries createdin this method and hence is faster.

Arguments:



void t(RRRot3by3& transpose) const;

Transpose method redefined forefficiency.

Arguments:

transpose Result of the transposeoperation.

void MultiplyWithTranspose(RRRot3by3& rrt) const;

Multiplies an RRRot3by3 with itstranspose. This method is redefinedfor efficiency.

Arguments:rrt Result of the multiplication.

void SetRotationAngles(const RRVector3D& axis, double theta, int angleType= 1 /* degrees */ );



412

This method sets the element of thematrix based on the rotation axis and

the angle of rotation. For example, if a rotation matrix has to be createdthat rotates about the ‘X’ axis by 45.0degrees, then the arguments to thismethod will be:RRVector3 axis(1.0, 0.0, 0.0);double theta = 45.0;

Arguments:

axis Axis about which to rotate.

theta Angle amount to rotate. AngleType 1 is degrees.

0 is radians.

RRRot3by3 operator-(const RRRot3by3& m) const;

Subtraction operator redefined forRRRot3by3 for efficiency.

void Subtract(const RRRot3by3& with, RRRot3by3& result) const;

Subtraction method. This is a faster

version of the above method as notemporaries are created in thismethod.

Arguments:

with Matrix to be subtracted.result Result of the subtraction.

result = this - with.

RRVector3 operator*(const RRVector3& ) const;

Multiply operator. Multiplies with anRRVector3.

RRRot3by3 operator-() const;

Negative operator redefined forefficiency.

RRRot3by3& operator-=(const RRRot3by3& m);

Self subtraction operator redefined

for RRRot3by3 for efficiency.Protected Methods

void m_alloc(int nrow, int ncol);

Method for allocating memory. Thisis redefined over here because theRRMatrix m_alloc method allocatesmemory on the heap and this methodallocates on the stack.

Arguments:nrow Number of rows = 3.

ncol Number of columns = 3.



413

B.2.9. Class RRTensor : public RRMatrix

#include <Math/Tensor.hpp>

Friend Member Functions

friend ostream& operator<<(ostream& strm, const RRTensor& t);

Output operator.

Public Methods

RRTensor(int nm = 1, RRMatrix* mp = 0, const RRString& name = "");

Constructor. Creates a tensor out of an array of matrices. The size of matrices in the mp array should all besame.

Arguments:

nm Number of matrices in mp.mp RRMatrix array.


RRTensor(int nm = 1, int Nrow = 1, int Ncol = 1, const RRString name = "");Constructor. Creates a tensor of size

nm X Nrow X Ncol and initializes allelements to 0.0.

Arguments:

nm Number of matrices in mp. Nrow Number of rows in a matrix.

Ncol Number of columns in a matrix.name Name of the object.

RRTensor(const RRTensor& t);

Copy constructor. Creates a tensorand copies all the elements of t into it.

~RRTensor();

Destructor. Deallocates memory.

int nMatrix() const;

Gets the number of rows in thematrices that comprise the tensor.

Return Value: The number of rows.

int nRow() const;

Gets the number of matrices in thetensor.

Return Value: The number of matrices.

int nCol() const;

Gets the number of columns in thematrices that comprise the tensor.

Return Value: The number of columns.

RRTensor& operator=(const RRTensor&);

Copy operator. Copies all theelements.

double& at(int i, int j, int k) const;Accesses or sets the i, j, k , element of the tensor. No range checking isperformed.

Arguments:

i j, k The element to access or set.Return Value: The i, j, k element.

double& operator()(int i, int j, int k) const;



414

Accesses or sets the i, j, k , element of the tensor. Range checking is

performed.

Arguments:

i j, k The element to access or set.

Return Value: The i, j, k element.RRMatrix& at(int i) const;

Accesses or sets the ith, plane of thetensor. No range checking isperformed.

Arguments:

i The plane (or matrix) to access orset.

Return Value: The ith plane or matrix.element.

RRMatrix& operator()(int i) const;

Accesses or sets the i, plane of thetensor. Range checking is performed.

Arguments:i The plane (or matrix) to access or

set.Return Value: The ith plane or matrix.



415

B.3. Robot Data Abstractions

B.3.1. class RRRobotData : public RRBase

Abstract Data Type

#include <RobotData/RobotData.hpp>

Public Methods

RRRobotData(const RRString& name = RRString(" "));

Constructor for Abstract class. Arguments:


RRRobotData(const RRRobotData&);

Copy constructor.

virtual ~RRRobotData();

Destructor

Protected Methods

void open(char* filename, ifstream& inFile);

Opens a file and returns the inputstream to the calling method.

Arguments:

filename File to open.inFile The input stream associated

with filename.

virtual void parseComments(ifstream& file, const char marker);

Move the file pointer till it encounters

a valid field. A comment field isspecified by marker . Every time the

marker character is encountered, theremaining line is ignored ascomments.

Arguments:

file File to parse.marker A character that specifies the start

of comments.

virtual int GetNoofEntries(ifstream& file, const char marker);

Method to compute the total numberof valid entries in the file.

Arguments: file File to parse.

marker A character that specifies the startof comments.

Return Value: The number of valid entriesin the file.

RRRobotData& operator=(const RRRobotData&);

Copy operator.



416

B.3.2. class RRMatrixData : public RRBase

#include <RobotData/MatrixData.hpp>


friend ostream& operator<<(ostream& strm, const RRMatrixData& M);

Output operator. Outputs the readdata in a matrix format.

Public Methods

RRMatrixData(char* filename, int noCols, char marker = ’#’, const RRString& name= RRString(" "));

Constructor. Reads the data file,parses the comments, and arranges

the read data in a matrix format.

Arguments:

filename File to open and read.

noCols Number of columns of datain the data file representedby filename.

marker Character that specifies thebeginning of a comment.


RRMatrixData(const RRMatrixData& md);

Copy constructor. Copies the storeddata into the new object.

~RRMatrixData();


const RRMatrix& GetParameters() const;

Returns the read data in a matrixformat.

Return Value: The read data in a matrixformat.

int GetNoRows() const;

Returns the number of rows read. Return Value: The number of rows of readdata.

RRVector GetRow(int rowNo) const;

Get a particular row of the read data. Arguments:rowNo The number of the row to get.Return Value: The data in the row rowNo.

double& operator()(int row, int col) const;

Access or set a particular element of

the read data.

Arguments:

row The row number of the element toaccess or set.

col The column number of the elementto access or set.

Return Value: The element at row, col.

RRMatrixData& operator=(const RRMatrixData& md);



417

Copy operator. Copies the data in the

md object.

Protected Methodsvirtual void loadParameters(ifstream& file, int noCol, const char marker);

Method that actually loads the datafrom the file.

Arguments:

filename File to open and read.noCols Number of columns of data

in the data file representedby filename.




418

B.3.3. class RRTensorData : public RRBase

#include <RobotData/TensorData.hpp>

friend ostream& operator<<(ostream& strm, const RRTensorData& I);

Output operator. Outputs the readdata in a tensor format.

Public Methods

RRTensorData(char* filename, int noRows, int noCols, char marker = ’#’, constRRString& name = RRString(" "));

Constructor. Reads the data file,parses the comments, and arrangesthe read data in a tensor format.

Arguments: filename File to open and read.

noRows Number of rows that will

make up a plane of thetensor in the data filerepresented by filename.

noCols Number of columns of datain the data file representedby filename.



RRTensorData(const RRTensorData& td);


RRTensorData& operator=(const RRTensorData& td);Copy operator. Copies the storeddata into the calling object.

~RRTensorData();


RRTensor& GetParameters() const;

Method to access the read data in atensor format.

Return Value: The read data in a tensorformat.

int GetNoPlanes() const;

Method to access the number of planes that constitute the tensor that

was formulated from the read data.

Return Value: The number of planes inthe tensor.

RRMatrix& operator()(int i) const;

Method to access a particular plane of the tensor that was formulated fromthe read data.

Arguments:

i The number of the plane to access.Return Value: The ith plane.

double& operator()(int i, int j, int k) const;



419

Method to access a particular elementof the tensor that was formulated

from the read data.

Arguments:

i, j, k The element of the tensor to access.

Return Value: The i, j, k element.

Protected Methods

virtual void loadparameters(ifstream&, int noRows, int noCols, const charmarker);

Method that actually loads the datafrom the file.

Arguments: filename File to open and read.

noRows Number of rows that willmake up a plane of thetensor in the data filerepresented by filename.

noCols Number of columns of data

in the data file representedby filename.




420

B.3.4. class RRDHData : public RRBase

#include <RobotData/DHData.hpp>


friend ostream& operator<<(ostream& strm, const RRDHData& D);

Output operator. Outputs the readdata in a tensor format.

Public Methods

RRDHData(char* filename, char marker = ’#’, const RRString name = RRString(""));

Constructor. Reads the data file,parses the comments, and arranges

the read DH parameters in a matrixformat.

Arguments:

filename File to open and read.

marker Character that specifies thebeginning of a comment.name Name of the object.

RRDHData(const RRDHData& dd);


RRDHData& operator=(const RRDHData& dd);

Copy operator. Copies the storeddata into the calling object.

~RRDHData();


int GetDOF(void) const;

Method to compute and access theDOF of the robot whose DHparameters were read.

Return Value: The DOF of the robot.

const RRMatrix& GetParameters() const;

Method to access the DH parametersin a matrix format.

double& operator()(int row, int col) const;

Access or set a particular element of the DH parameters that are stored in amatrix format.

Arguments:

row the row of the element to access orset.

col the column of the element to access

or set.Return Value: the row, col element.

char GetJointType(int joint) const;



421

Get the joint type of a particular joint. Arguments:

joint The joint number whose type is

desired.Return Value: ‘P’ if joint is prismatic.

‘R’ if joint is revolute.



422

B.4. Forward Kinematics Abstractions

B.4.1. class RRFKPosition : public RRBase

#include <ForwardKinematics/FKPosition.hpp>

Public Methods

RRFKPosition(char* filename, const RRString& name = RRString(" "));

Constructor. Constructs anRRFKPosition object based on theDH parameters given in filename.

Memory is allocated for the local and

global transformations over here.

Arguments:

filename File containing the DHparameters.


RRFKPosition(const RRFKPosition&);

Copy constructor. Copies all theattributes and the current state of allthe local and global transformationmatrices.

virtual ~RRFKPosition();

Destructor. Deallocates all memory.

void SetToolPoint(const RRVector3D& toolPointVector);

Sets the tool point. Arguments:toolPointVector A size 3 vector specifying

the X, Y, and Z position of

the tool point as expressedin the local frame of thelast link.

int GetToolPoint(RRVector3D& toolPointVector) const;

Gets the tool point. Arguments:

toolPointVector The tool point vector.Return Value: 1 if tool point was

previously set.0 if tool point notpreviously set.

void SetRobotLocation(RRVector3D& location);

Sets the robot location. The robotlocation is expressed as a positionvector whose X, Y, and Z coordinatesexpressed in the world frame specifythe location of the robot base frame.

Arguments:location A size 3 vector specifying

the X, Y, and Z position of the robot base frame asexpressed in the worldcoordinate system.



423

int GetRobotLocation(RRVector3D& location) const;

Gets the robot location. Arguments:

location The robot location.Return Value: 1 if location was previously

set.0 if location was notpreviously set.

const RRXform* GetHandPose(const RRVector& inputJoints);

Method computes and returns apointer to the hand transformationthat is computed based on theinputJoints.

Arguments:inputJoints A vector holding the joint

positions for which theforward position solutionhas to be computed.

Return Value: A pointer to the computed

hand matrix.const RRXform* GetLocalTransformation(int linkNo) const;

This method returns a pointer to thelocal transformation matrix for thelinkNo joint. This localtransformation was computed duringthe last call to any of the othermethods with a joint vector as theargument.

Arguments:

linkNo The number of the link forwhich the local transform-ation matrix is desired.

Return Value: A pointer to the localtransformation matrix.

const RRXform* GetLocalTransformation(int linkNo, const RRVector& jointAngles);

This method returns a pointer to thelocal transformation matrix for the

linkNo joint. All the localtransformation matrices are computedfor the input joint vector jointAngles.

Arguments:linkNo The number of the link forwhich the local transform-ation matrix is desired.

jointAngles A vector holding the jointpositions for which theforward position solutionhas to be computed.


const RRXform* GetGlobalTransformation(int linkNo) const;

This method returns a pointer to the

global transformation matrix for thelinkNo joint. This globaltransformation was computed duringthe last call to any of the othermethods with a joint vector as theargument.

Arguments:

linkNo The number of the link forwhich the globaltransformation matrix isdesired.

Return Value: A pointer to the globaltransformation matrix.



424

const RRXform* GetGlobalTransformation(int linkNo, const RRVector& jointAngles);

This method returns a pointer to theglobal transformation matrix for thelinkNo joint. All the globaltransformation matrices are computedfor the input joint vector jointAngles.

Arguments:linkNo The number of the link for

which the globaltransformation matrix isdesired.

jointAngles A vector holding the jointpositions for which theforward position solutionhas to be computed.


const RRXform* GetAllLocalTransformations() const;

This method returns a pointer to anarray of RRXform’s that holds thelocal transformation matrices (size =DOF of the robot). These localtransformations were computedduring the last call to any of the othermethods with a joint vector as theargument.

Return Value: A pointer to the localtransformation matricesarray.

const RRXform* GetAllLocalTransformations(const RRVector& jointAngles);

This method returns a pointer to thearray of local transformationmatrices. All the localtransformations matrices arecomputed for the input joint vector

jointAngles.

Arguments: jointAngles A vector holding the joint


Return Value: A pointer to the array of local transformationmatrices.

const RRXform* GetAllGlobalTransformations() const;

This method returns a pointer to anarray of RRXform’s that holds theglobal transformation matrices (size =DOF of the robot). These globaltransformations were computed

during the last call to any of the othermethods with a joint vector as theargument.

Return Value: A pointer to the globaltransformation matricesarray.

const RRXform* GetAllGlobalTransformations(const RRVector& jointAngles);



425

This method returns a pointer to thearray of global transformation

matrices. All the globaltransformations matrices arecomputed for the input joint vector

jointAngles.

Arguments:

jointAngles A vector holding the joint


Return Value: A pointer to the array of global transformationmatrices.

char GetJointType(int jointNo);

Method to access the type of aparticular joint.

Arguments: jointNo The number of the joint

whose type is desired.Return Value: ‘P’ if prismatic.

‘R’ if revolute.

int GetDOF(void) const;Method to access the DOF of therobot whose DH parameters wereused for the construction of thisobject.

Return Value: The DOF.

RRFKPosition& operator=(const RRFKPosition&);

Copy operator. Copies all attributesand transformation matrices.

Protected Methods

virtual void calculateTransformations(const RRVector& jointAngles);

This method compute all the local

transformation matrices by callingcalculateLinkTransformationsrepeatedly.

Arguments:

jointAngles A vector of joint positions.

virtual void calculateLinkTransformation(int jointNo, double jointValue);

This method compute a particularlocal transformation matrix. Thismethod can be redefined if aconvention other than the DHparameter convention is used.

Arguments:

joinNo The joint number for whichthe local transformation hasto be computed.

jointValue The position of the joint

jointNo.

virtual void calculateLinkToBaseTransformations(const RRVector& jointPos);

This method computes the global

transformation matrices based on theinput joint positions ( jointPos). Thismethod basically multiplies the localtransformation matrices.

Arguments:

jointPos A vector of joint positions.

void makeToolPointAdjustment(void);



426

This method modifies the globaltransformation matrix of the last joint

based on the tool-point vector.void makeRobotLocationAdjustment(void);

This method modifies the localtransformation matrix of the first jointbased on the robot location vector.



427

B.4.2. class RRFKJacobian : public RRFKPosition

#include <ForwardKinematics/FKJacobian.hpp>

Public Methods

RRFKJacobian(char* filename);

Constructor. Allocates memory. Arguments: filename File containing the DH

parameters.

RRFKJacobian(const RRFKJacobian&);

Copy constructor. Copies allattributes and the current state of theJacobian and Jacobian transpose

matrices.RRFKJacobian& operator=(const RRFKJacobian&);

Copy operator. Copies all attributesand the current state of the Jacobianand Jacobian transpose matrices.

virtual ~RRFKJacobian();


const RRMatrix* GetJacobian(void);

Method to compute the Jacobianmatrix. This method returns the jacobian matrix corresponding to the joint positions that were used in thelast call to any of the methods in theRRFKPosition class that took jointpositions as the argument.

Return Value: A constant pointer to theJacobian matrix.

const RRMatrix* GetJacobian(const RRVector& jointPosition);

Method to compute the Jacobianmatrix. This method returns the jacobian matrix corresponding to the jointPosition argument.

Arguments: jointPosition The position of the joints.Return Value: A constant pointer to the

Jacobian matrix.

const RRMatrix* GetJacobianTranspose(int flag = 0) ;



428

Method to access the transpose of theJacobian matrix. The Jacobian

transpose was automaticallycomputed in the last call toGetJacobian. However, if GetJacobian was previously notcalled, the argument flag should be 0in order to compute the Jacobian andits transpose based on the currentstate of the transformation matrices.

Arguments:

flag 0 if Jacobian and its transpose

should be computed.1 if the current Jacobian transposeis desired.

Return Value: A constant pointer to theJacobian transpose matrix.

const RRMatrix* GetJacobianTranspose(const RRVector& jointPosition);

Method to compute and access thetranspose of the Jacobian matrix. TheJacobian and its transpose is

computed based on jointPosition.

Arguments: jointPosition The location of the joints

for which the Jacobian

transpose needs to becomputed.

Return Value: A constant pointer to theJacobian transpose matrix.

Protected Methods

void calculateJacobian(void);

Method that actually computes theJacobian and its transpose. Thismethod further callscalculateJacobianColumn to computethe various columns of the Jacobian

matrix.virtual void calculateJacobianColumn(int jointNo);

Method to compute a particularcolumn of the Jacobian matrix. Thismethod can be redefined in derivedclasses, if a different scheme forJacobian computation has to be used.

Arguments:

jointNo The joint number for which theJacobian column has to becomputed.



429

B.4.3. class RRFKPartialJacobian : public RRFKJacobian

#include <ForwardKinematics/FKPartialJacobian.hpp>

Public Method

RRFKPartialJacobian(char* filename);

Constructor. Allocates memory.This class is used to calculate theJacobian matrix for any six joints of aserial robot that has more than sixDOF.

Arguments: filename The name of the file

containing the DHparameters.

RRFKPartialJacobian(const RRFKPartialJacobian&);

Copy constructor. Allocates memory

and copies all the data members.RRFKPartialJacobian& operator=(const RRFKPartialJacobian&);

Copy operator. Allocates memoryand copies all the data members.

~RRFKPartialJacobian();


int LockJoints(const RRVector& lockedJoints, const RRVector& lockValues);

This method is used to select the six joints that are to be used for Jacobiancalculation. The joints to be excludedare known as the locked joints. For an DOF robot, n-6 joints should

always be locked. By default, thefirst n-6 joints are locked when theobject is constructed.

Arguments:

lockedJoints A vector that holds the jointnumbers of the joints thatare to be locked. That is,the joints that have to be

excluded from the Jacobiancalculation. The size of this should be DOF-6.

lockValues This vector holds theposition of the locked joints. That is the positionat which each joint islocked. The size of thisshould be DOF-6.

Return Value: 1 if no error.-1 if lockedJoints andlockValues are not of thesame size or if their size isnot equal to DOF-6

char GetJointStatus(int jointNo) const;



430

Method to access the status of a joint. Arguments:

jointNo The number of the joint

whose status is desired.Return Value: ’U’ if joint is unlocked.

’L’ if joint is locked.

const char* GetJointStatus(void) const;

Method to access the status of all the joints.

Return Value: A character array of sizeDOF that holds the statusof all joints. ’U’ if joint isunlocked. ’L’ if joint islocked.

double GetJointLockValue(int jointNo) const;

Method to access position at which a joint is locked.

Arguments: jointNo The joint for which the

locked value is desired.Return Value: A character array of size

DOF that holds the statusof all joints. ’U’ if joint isunlocked. ’L’ if joint islocked.

int GetLockedJoints(RRVector& lockedJoints, RRVector& lockedValues) const;

This method is used to access the joint numbers of the locked joints andvalues at which they are locked.

Arguments:lockedJoints A vector that holds the joint

numbers of the joints thatare locked. The size of thisshould be DOF-6.

lockValues This vector holds theposition of the locked joints. The size of thisshould be DOF-6.

Return Value: 1.

int SetLockedJoints(const RRVector& lockValues);

Set the locked values of the locked joints.

Arguments:

lockValues This vector holds theposition of the locked joints. That is the positionat which each joint is

locked. The size of thisshould be DOF-6.

Return Value: 1 if no error.0 if lockValues is not of size DOF-6.

const RRMatrix* GetPartialJacobian(void);



431

Computes and gets the partialJacobian. The computation is based

on the current status of the globaltransformation matrices.

Return Value: A constant pointer to a6 X 6 partial Jacobian

matrix.

const RRMatrix* GetPartialJacobian(const RRVector& jointPosition);

Computes and gets the partialJacobian. The computation is basedon the current status of the global onthe jointPosition arguments.

Arguments: jointPosition Joint position of the robot

for which the partialJacobian has to becomputed.

Return Value: A constant pointer to a6 X 6 partial Jacobianmatrix.



432

B.4.4. class RRFKVelocity : public RRFKJacobian

#include <ForwardKinematics/FKVelocity.hpp>

Public Methods

RRFKVelocity(char* filename);

Constructor. Allocates memory.This class is used to calculate thefirst-order kinematic influencecoefficients.

Arguments: filename The name of the file

containing the DHparameters.

RRFKVelocity(const RRFKVelocity& fkv);

Copy constructor. Allocates memory.

Copies all the data members.RRFKVelocity& operator=(const RRFKVelocity& fkv);

Copy operator. Copies all the datamembers.

virtual ~RRFKVelocity();


void SetLinkPoints(const RRMatrix& localPositions);

Method to set the location of pointson the robot links. The position of these points should be described inthe local link coordinates.

Arguments:

localPositions A matrix of size 3 X DOF.Each column shouldcontain the position of apoint (x, y, and z

coordinates) for which thetranslational G functionshave to be computed.

const RRTensor* GetRotationalGfunctions(void);

Method to compute the rotationalfirst-order influence coefficients. Thecurrent state of the globaltransformation matrices is used forthe computation.

Return Value: A constant pointer to atensor of size DOF X 3 XDOF that contains therotational G functions.

const RRTensor* GetRotationalGfunctions(const RRVector& jointPos);



433

Method to compute the rotationalfirst-order influence coefficients. The

joint positions described in jointPosare used for the computation.

Arguments:

jointPos A vector of size DOF that

contains the joint positionsfor which the rotational Gfunctions have to becomputed.

Return Value: A constant pointer to atensor of size DOF X 3 XDOF that contains therotational G functions.

const RRTensor* GetTranslationalGfunctions(void);

Method to compute the translationalfirst-order influence coefficients. Thecurrent state of the global

transformation matrices is used forthe computation.

Return Value: A constant pointer to atensor of size DOF X 3 XDOF that contains the

translational G functions.

const RRTensor* GetTranslationalGfunctions(const RRVector& jointPos);

Method to compute the translationalfirst-order influence coefficients. The joint positions described in jointPos

are used for the computation.

Arguments:

jointPos A vector of size DOF thatcontains the joint positionsfor which the translationalG functions have to becomputed.

Return Value: A constant pointer to atensor of size DOF X 3 XDOF that contains thetranslational G functions.



434

B.4.5. class RRFKAcceleration : public RRFKVelocity

#include <ForwardKinematics/FKAcceleration.hpp>

Public Methods

RRFKAcceleration(char* filename);

Constructor. Allocates memory.This class is used to calculate thesecond-order kinematic influencecoefficients.

Arguments:

filename The name of the filecontaining the DHparameters.

RRFKAcceleration(const RRFKAcceleration& fka);

Copy constructor. Allocates memory.Copies all the data members.

RRFKAcceleration& operator=(const RRFKAcceleration& fka);Copy operator. Copies all the datamembers.

virtual ~RRFKAcceleration();


const RRTensor* GetRotationalHfunctions(int linkNo);

Method for computing and getting therotational H function (or second-orderrotational influence coefficient). Thecurrent state of the globaltransformation matrices is used forthe computation.

Arguments:

linkNo Number of the link for which therotational H function is desired.

Return Value: A pointer to a tensorcontaining the rotational Hfunction for linkNo.

const RRTensor* GetRotationalHfunctions(int linkNo, const RRVector& jntPos);

Method for computing and getting therotational H function (or second-orderrotational influence coefficient). Therotational H function is computedbased on the joint position given in

jntPos.

Arguments:


jntPos Vector of joint positions for whichthe rotational H function is desired.

Return Value: A pointer to a tensorcontaining the rotational Hfunction for linkNo.

const RRTensorP* GetRotationalHfunctions(void);

Method for computing and getting all

the rotational H function (or second-order rotational influencecoefficient). The current state of theglobal transformation matrices is usedfor the computation.

Return Value: A pointer to an array of

tensor pointers. Eachpointer in this array pointsto a tensor containing therotational H function for aparticular link.

const RRTensorP* GetRotationalHfunctions(const RRVector& jntPos);



435

Method for computing and getting allthe rotational H function (or second-

order rotational influencecoefficient). The rotational Hfunction is computed based on the joint position given in jntPos.

Arguments:

jntPos Vector of joint positions for which

the rotational H function is desired.Return Value: A pointer to an array of

tensor pointers. Eachpointer in this array pointsto a tensor containing therotational H function for aparticular link.

const RRTensor* GetTranslationalHfunctions(int linkNo);

Method for computing and getting thetranslational H function (or second-order translational influencecoefficient). The current state of the

global transformation matrices andthe first-order influence coefficientsis used for the computation.

Arguments:

linkNo Number of the link for which thetranslational H function is desired.

Return Value: A pointer to a tensor

containing the translationalH function for linkNo.

Const RRTensor* GetTranslationalHfunctions(int linkNo, const RRVector& jntPos);

Method for computing and getting thetranslational H function (or second-order translational influencecoefficient). The translational Hfunction is computed based on the joint position given in jntPos.

Arguments:


jntPos Vector of joint positions for whichthe rotational H function is desired.

Return Value: A pointer to a tensorcontaining the translationalH function for linkNo.

Const RRTensorP* GetTranslationalHfunctions(void);

Method for computing and getting allthe translational H function (orsecond-order translational influencecoefficient). The current state of theglobal transformation matrices andthe first-order influence coefficientsis used for the computation.

Return Value: A pointer to an array of tensor pointers. Eachpointer in this array pointsto a tensor containing thetranslational H function fora particular link.

Const RRTensorP* GetTranslationalHfunctions(const RRVector& jntPos);



436

Method for computing and getting allthe translational H function (or

second-order translational influencecoefficient). The translational Hfunction is computed based on the joint position given in jntPos.

Arguments:

jntPos Vector of joint positions for which

the translational H function isdesired.

Return Value: A pointer to an array of tensor pointers. Eachpointer in this array pointsto a tensor containing thetranslational H function fora particular link.



437

B.5. Inverse Kinematics Abstractions

B.5.1. class RRIKPosition : public RRBase

Abstract Data Type

#include <InverseKinematics/IKPosition.hpp>

Public Methods

RRIKPosition(const RRString& name = RRString(" ") );

Constructor. Abstract class forspecifying the interface for inversekinematics at the position-level.

Arguments:name Name of the object

~RRIKPosition();

Destructor

virtual double GetJointPosition(const RRXform& hand, RRVector& jointSol) = 0;

This method is used to compute theinverse position solution. Thefunctionality for this has to besupplied in the derived classes.

Arguments:

hand The end-effector position andorientation specified in 4X4 form.

JointSol The joint angle solutionReturn Value: Less than equal to 0 if a

singularity wasencountered. Otherwisea positive number can be

returned that givesinformation about thequality of the solution

virtual double GetJointPosition(const RRHandPose&, RRVector&) = 0;

This method is used to compute theinverse position solution. Thefunctionality for this has to besupplied in the derived classes.

Arguments:hand The end-effector position and

orientation specified as a vector. JointSol The joint angle solutionReturn Value: Less than equal to 0 if a

singularity wasencountered. Otherwise

a positive number can be

returned that givesinformation about thequality of the solution

virtual void SetToolPoint(const RRVector3D& toolPoint) = 0;



438

This method is used to set thelocation of the tool-point. The tool

point is specified as a threedimensional position vector that isexpressed in the local coordinates of the last link.

Arguments:

toolPoint A vector specifying the

‘X’, ‘Y’, and ‘Z’coordinates of the toolpoint.

Virtual void SetRobotLocation(const RRVector3D& location) = 0;This method is used to set thelocation of the base frame of therobot with respect to a worldcoordinate frame. The location isspecified as a three dimensionalposition vector that is expressed inthe local coordinates of the world

frame.

Arguments:

location A vector specifying the‘X’, ‘Y’, and ‘Z’coordinates of the locationof the robot.

virtual int GetToolPoint(RRVector3D& toolPoint) const = 0;This method is used to access thetool-point.

Arguments:

toolPoint A vector in which the tool-point vector is stored.

Return Value 1 if the tool-point waspreviously set.

0 if the tool-point has notbeen set

virtual int GetRobotLocation(RRVector3D& location) const = 0;This method is used to access the

robot location.

Arguments:

location A vector in which the robotlocation is stored.

Return Value 1 if the location waspreviously set.0 if the location has notbeen set.



439

B.5.2. class RRIKVelocity : public RRIKPosition

Abstract Data Type

#include <InverseKinematics/IKVelocity.hpp>

Public Methods

RRIKVelocity(const RRString& name = RRString(" ") );

Constructor. Abstract class forspecifying the interface for inversekinematics at the velocity-level.

Arguments:


~RRIKVelocity();

Destructor.

virtual const RRVector* GetJointVelocity(const RRHandPose& handVel) = 0;

A virtual method that specifies theinterface for computing the inversekinematics solution at the velocity-level.

Arguments:

handVel A vector specifying thehand velocity.

Return Value: A pointer to a vector thatcontains the computed jointvelocities



440

B.5.3. class RRIKJacobian : public RRIKVelocity

Abstract Data Type

#include <InverseKinematics/IKJacobian.hpp>

Public Methods

double GetJointPosition(const RRXform& hand, RRVector& jointSol);

This method is used to compute theinverse position solution.

Arguments:

hand The end-effector position andorientation specified in 4X4 form.

jointSol The joint angle solutionReturn Value: Less than equal to 0 if a

singularity was

encountered. Otherwisethe measure of manipulability is returned

double GetJointPosition(const RRHandPose& hand, RRVector& jointSol);

This method is used to compute theinverse position solution.

Arguments:

hand The end-effector position andorientation specified as a vector

jointSol The joint angle solutionReturn Value: Less than equal to 0 if a

singularity wasencountered. Otherwise

the measure of manipulability is returned

void GetJointPosition(RRVector& currPos) const;

This method is used to access thestate of the last computed jointsolution.

Arguments:currPos The state of the current

joint position is returned inthis argument

void SetMinimumMOM(double minMOM);

This method is used to set theminimum acceptable value of themeasure of manipulability (MOM). If the computed MOM becomes less

than this value, a singularity isflagged.

Arguments:minMOM The minimum acceptable

value of the measure of manipulability

const RRVector* GetJointVelocity(const RRHandPose& handVel);



441

A method for computing the jointvelocities corresponding to a desired

hand velocity. This method should becalled after a successful call toGetJointPosition.

Arguments:

handVel A vector specifying the

hand velocity.Return Value: A pointer to a vector that

contains the computed jointvelocities

void SetToolPoint(const RRVector3D& toolPoint);

This method is used to set thelocation of the tool-point. The toolpoint is specified as a threedimensional position vector that isexpressed in the local coordinates of the last link.

Arguments:toolPoint A vector specifying the

‘X’, ‘Y’, and ‘Z’coordinates of the toolpoint.

void SetRobotLocation(const RRVector3D& location);

This method is used to set thelocation of the base frame of therobot with respect to a worldcoordinate frame. The location isspecified as a three dimensionalposition vector that is expressed inthe local coordinates of the worldframe.

Arguments:location A vector specifying the

‘X’, ‘Y’, and ‘Z’coordinates of the locationof the robot.

int SetJointPosition(const RRVector& jointPos);

This method is used to set the currentstate of the joint positions of therobot. This method is similar toresetting the initial jointconfiguration.

Arguments: jointPos A vector specifying the

current joint position of therobot.

int GetToolPoint(RRVector3D& toolPoint) const;

This method is used to access thetool-point.

Arguments:toolPoint A vector in which the tool-

point vector is stored.Return Value 1 if the tool-point was

previously set.0 if the tool-point has notbeen set

int GetRobotLocation(RRVector3D& location) const;



442

This method is used to access therobot location.

Arguments:

location A vector in which the robot

location is stored.Return Value 1 if the location was

previously set.0 if the location has notbeen set

void SetMaximumIterations(unsigned int noIterations);

The inverse kinematics schemeimplemented in this class relies oniteration. This method allows thesetting of an upper bound to theiterations.

Arguments:

noIterations An upper bound to thenumber of iterations. If thisupper bound is reached, theGetJointPosition methodreturns with an error code.

unsigned int GetMaximumIterations(void) const;Method for accessing the upperbound on the iterations.

Return Value: The upper bound on theiterations.

int GetDOF() const;

Method for accessing the DOF forwhich the inverse solution is beingcomputed.

Return Value: The DOF

Protected Methods

RRIKJacobian(const RRString& filename, RRVector& initialJoint, doublemaxError = 0.1, double rotScale = 1000.0, RRFKJacobian* fkJacobian = 0);



443

Constructor. This allocates memoryfor various data members and

initializes variables.

Arguments:

filename File containing the DH

parameters of the robot forwhich the inverse has to becomputed.

initialJoint The initial jointconfiguration of the robotunder question.

maxError The maximum desirederror. When the errorbecomes less than thisvalue, the iteration stops.

rotScale This is used to amplify theorientation error. The

orientation error ismultiplied by rotScale andadded to the position errorto compute the overallerror.

fkJacobian This argument is used tosupply a pointer to aRRFKJacobian object thatis used internally inside thisclass. If no argument issupplied, an RRFKJacobianobject is created internally.

virtual ~RRIKJacobian();Destructor. Deallocates memory.

virtual double converge(const RRXform& desiredHand);

This method defines the functionalityfor iterating till the error bounds aresatisfied or a singularity results.

Arguments:

desiredHand The hand transformationmatrix for which the jointsolution is to be computed

Return Value: The measure of manipulability of the jointsolution

virtual double calculateDifferentialJointVector(const RRHandPose& errorHand,

RRVector* differentialJoint) = 0;



444

This is a key method of this class andit is used to compute the differential

joint vector based on a givendifferential or error hand vector. It isin this method that the Jacobian isinverted and the desired optimizationsapplied. Functionality for thismethod is supplied in the derivedclasses.

Arguments:

errorHand The error hand vector or

the differential hand vector.differentialJoint The corresponding

computed differential jointvector

Return Value: The measure of manipulability that resultedfrom the inversion of theJacobian matrix.

virtual double calculateErrorMagnitude(const RRXform& desiredHand,const RRXform* currentHand, RRHandPose& errorHand);

This method is used to compute theerror between the desired hand

location and the current hand locationcomputed in the iteration loop. Theerror is computed by first finding aerror transformation matrix and thenconverting it into its equivalent axisrepresentation. From the equivalentaxis representation a error handvector is computed.

Arguments:

desiredHand The desired hand

transformation matrix.currentHand The state of the

transformation matrixinside the iteration loop.

errorHand The error hand vector.Return Value: The magnitude of the error

hand vector.



445

B.5.4. class RRIKJForSix : public RRIKJacobian

#include <InverseKinematics/IKJForSix.hpp>

Public Methods

RRIKJForSix(const RRString& filename, RRVector& initialJoint, doublemaxError = 0.1, double rotScale = 100.0, RRFKJacobian* fkJacobian = 0);

Constructor. This allocates memoryfor various data members andinitializes variables. This classshould be used for computing thegeneralized inverse solution for sixDOF robots.

Arguments:

filename File containing the DHparameters of the robot forwhich the inverse has to becomputed.

initialJoint The initial joint

configuration of the robotunder question.maxError The maximum desired

error. When the errorbecomes less than thisvalue, the iteration stops.

rotScale This is used to amplify theorientation error. Theorientation error ismultiplied by rotScale

and added to the positionerror to compute the

overall error. fkJacobian This argument is used to

supply a pointer to aRRFKJacobian object thatis used internally insidethis class. If no argumentis supplied, anRRFKJacobian object iscreated internally.

~RRIKJForSix();


Protected Methods

virtual double calculateDifferentialJointVector(const RRHandPose& errorHand,RRVector* differentialJoint);



446

This method computes thedifferential joint vector by

multiplying the error hand vectorwith the inverse of the Jacobianmatrix.

Arguments:


the differential handvector.

differentialJoint The correspondingcomputed differential jointvector




447

B.5.5. class RRIKJForGTSix : public RRIKJacobian

#include <InverseKinematics/IKJForGTSix.hpp>

Public Methods

RRIKJForGTSix(const RRString& filename, RRVector& initialJoint, doublemaxError = 0.1, double rotScale = 100.0, RRFKJacobian* fkJacobian = 0);

Constructor. This allocates memoryfor various data members andinitializes variables. This classshould be used for computing thegeneralized inverse solution for serialrobots with greater than six DOF

robots.

Arguments:









~RRIKJForGTSix();


Protected Methods




448

This method computes thedifferential joint vector by

multiplying the error hand vectorwith the pseudo-inverse of theJacobian matrix.

Arguments:







449

B.5.6. class RRIKJPartial : public RRIKJacobian

#include <InverseKinematics/IKJPartial.hpp>

Public Methods

RRIKJPartial( const RRString& filename, RRVector& initialJoint, doublemaxError = 0.1, double rotScale = 1000.0, RRFKPartialJacobian* fkJacobian = 0);

Constructor. This allocates memoryfor various data members andinitializes variables. This classshould be used for computing thegeneralized inverse solution for serialrobots with greater than six DOF

robots. By default, when this objectis created, the last six joints of therobot are selected as the active joints.The first DOF-6 joints are assumedto be locked at the joint positionsspecified in the initiaJoint vector.

Arguments:









~RRIKJPartial();


int LockJoints(const RRVector& lockedJoints, const RRVector& lockValues);



450

This method is used to specify the joints that are to be excluded from

the generalized inverse.

Arguments:

lockedJoints A vector that holds the

joint numbers of the jointsthat have to be locked.The size of this vectorshould always be degrees-of-freedom - 6.

lockValues This vector holds thecorresponding positions of the joints that are specifiedin the lockedJoints.

Return Value: 1 if successful0 if unsuccessful

char GetJointStatus(int jointNo);

Method to access the status of a joint.That is, whether a joint is locked(excluded from the inverse) orunlocked (actively used in theinverse)

Return Value: ‘L’ if joint is locked‘U’ if joint is unlocked

const char* GetJointStatus(void);

Method to access the status of all the joints.

Return Value: A character array of sizeDOF that holds ‘L’sand ‘U’s.

double GetJointLockValue(int jointNo);

Method to access the joint position of a locked joint.

Arguments

jointNo Joint whose lockedposition has to beaccessed.

Return Value: The locked position of a joint.

int GetLockedJoints(RRVector& lockedJoints, RRVector& lockedValues)const;



451

Method is access the joint numbersof the joints that are locked and the

joint positions that they are locked at.

Arguments:

lockedJoints A vector that holds the

joint numbers of the jointsthat are locked. The sizeof this vector shouldalways be degrees-of-freedom - 6.

lockValues This vector holds thecorresponding positions of the joints that are locked


int SetJointPosition(const RRVector& jointPos);

This method is used to update the

state of the current joint position.The locked values of the locked joints is also updated in this method.

Arguments:

jointPos A vector specifying the joint positions of all the joints.


Protected Methods

virtual double converge(const RRXform& desiredHand);

This method defines the functionalityfor iterating till the error bounds aresatisfied or a singularity results. Thismethod is redefined over here to take

into account the locking andunlocking of the joints.

Arguments:

desiredHand The hand transformationmatrix for which the jointsolution is to be computed

Return Value: The measure of manipulability of the jointsolution


This method computes thedifferential joint vector bymultiplying the error hand vectorwith the inverse of the Jacobianmatrix.

Arguments:errorHand The error hand vector or






452

B.6. Performance Criteria Abstractions

B.6.1. class RRPerformanceCriteria : public RRBase

Abstract Data Type

#include <PerformanceCriteria/PerformanceCriteria.hpp>

Public Methods

RRPerformanceCriteria(unsigned int maxNoSols, MINORMAX minOrMax =MINIMIZE, unsigned int weight = 1, const RRString& name = RRString(" "));

Constructor. This class implementsan abstract data type for all types of performance criteria.

Arguments:

maxNoSols The maximum number of solutions this performancecriteria will be asked tocompute criteria valuesand rank

minOrMax Minimize or maximize thecriteria. If minimize, thenthe joint option with theminimum criteria will be atthe top and vice versa

weight The weight of the criteria.name The name of the object.

RRPerformanceCriteria(const RRPerformanceCriteria& crit);Copy constructor. Creates aduplicate.

virtual ~RRPerformanceCriteria();


RRPerformanceCriteria& operator=(const RRPerformanceCriteria& _crit);

Copy operator. Copies all attributesand state.

int PickSolution(const RRMatrix& solutions, RRCriteriaValue* sortedSols);



453

This method is used to rank a set of joint space options based on their

criteria values. This methodinternally calls computeCriteria tocompute the criteria values. ThensortSolutions is called to rank theoptions.

Arguments:

solutions A matrix whose each row

holds a joint solution. Thelast element of each rowshould hold the measure of manipulability of thesolution.

sortedSols This data type holds theranked joint solutions andtheir corresponding criteriavalues.

Return Value: Number of solutions thatwere non-singular or -1 if an error occurred during

criteria computation.void SetWeight(unsigned int weight);

This method is used to set the weightof a criteria.

Arguments:

weight The desired weight of the criteria.

unsigned int GetWeight(void) const;

This method is used to access theweight of a criteria.

Return Value: The weight of the criteria.

void SetDirection(MINORMAX minOrMax);

This method is used to set whetherthe criteria has to be maximized orminimized

Arguments:

minOrMax MINIMIZE if the criteriahas to be minimized.MAXIMIZE if the criteriahas to be maximized.

MINORMAX GetDirection(void) const;

Method to access whether the criteriais being maximized or minimized

ArgumentsReturn Value MINIMIZE if the criteria

is being minimized.MAXIMIZE if the criteriais being maximized.

void SetMaximumSolutions(unsigned int maxNoSols);

Method sets the maximum number of joint space options that will be inputinto this criteria for evaluation. This

method could have been avoided, butis primarily made available forcomputational efficiency

Arguments:maxNoSols The maximum number of

joint space options that

have to be evaluated

unsigned int GetMaximumSolutions(void) const;



454

Method accesses the maximumnumber of joint space options that

will be input into this criteria forevaluation. This method could havebeen avoided, but is primarily madeavailable for computationalefficiency

Arguments:

maxNoSols The maximum number of

joint space options thathave to be evaluated

Protected Methods

virtual unsigned int sortSolutions(RRCriteriaValue* critVals, unsigned int noSols);

This method sorts the various criteriavalues and the joint space optionsassociated with them. It utilizes aquick sort to do the sorting. Derivedclasses can redefine the sorting

functionality.

Arguments:critVals A dual vector of criteria

values and the joint spaceoptions that has to besorted.

noSols No of solutions to besorted.

Return Value: The number of the bestsolution.

virtual int computeCriteria(const RRMatrix& sols, RRCriteriaValue* critVals) = 0;

This pure virtual method provides theinterface for computing the criteriavalues based on a given set of solutions. Functionality to computethe criteria value is to be provided inderived classes.

Arguments:

sols The solutions to be sorted. Eachrow of this matrix holds a solutionwith the last element of each rowholding he measure of manipulability of the solution..

crtiVals The computed criteriavalues and the associatedsolution number go in this.This array should be of size equal to the number of rows of sols.

Return Value: 0 if all solutions aresingular-1 if an error occurred incriteria computation.1 if okay.



455

B.6.2. class RRPCAvoidLimits : public RRPerformanceCriteria

#include <PerformanceCriteria/PCAvoidLimits.hpp>

Public Methods

RRPCAvoidLimits(const RRString& limitsFile, unsigned int maxNoSols,MINORMAX minOrMax = MINIMIZE, unsigned int weight = 1, const RRString&name = RRString(" "));

Constructor. This class implements aperformance criteria that tends tomaximize the joint range availabilityor in other words avoids joint limits.

Arguments:limitsFile Name of the file that

contains the joint limitdata. This data isorganized in two columns

and number of rows equalto the number of joints of the robot.


minOrMax Minimize or maximize thecriteria. If minimize, thenthe joint option with theminimum criteria will be at

the top and vice versaweight The weight of the criteria.name The name of the object.

RRPCAvoidLimits(const RRPCAvoidLimits& crit);

Copy constructor. Creates aduplicate.

virtual ~RRPCAvoidLimits();


RRPCAvoidLimits& operator=(const RRPCAvoidLimits& _crit);


const RRMatrix& GetJointLimits(void) const;

Method to access the joint limits of the robot in question. These jointlimits were read from a data fileduring construction.

Return Value: A matrix of size DOF X 2that contains the jointlimits of the robot inquestion.

void GetJointLimits(RRMatrix& limits) const;



456

Method to access the joint limits of the robot in question. These joint

limits were read from a data fileduring construction. This methodshould be preferred over the previousone as it does not create anytemporary local variables.

Arguments:

limits A matrix of size DOF X 2 that

contains the joint limits of therobot in question.

const RRVector& GetJointRange(void) const;

Method to access the range of all the joints based on the joint limits data.

Return Value: A vector of size DOF thatholds the range of each joint.

void GetJointRange(RRVector& range) const;

Method to access the range of all the joints based on the joint limits data.

This method should be preferred overthe previous one as there are notemporaries created inside it.

Arguments:range: A vector of size DOF that holds

the range of each joint.

const RRVector& GetJointMedian(void) const;

Method to access the median value of all the joints based on the joint limitsdata.

Return Value: A vector of size DOF thatholds the median of each joint.

void GetJointMedian(RRVector& _median) const;

Method to access the median of allthe joints based on the joint limitsdata. This method should be

preferred over the previous one asthere are no temporaries createdinside it.

Arguments:

median A vector of size DOF thatholds the range of each

joint.

int SetJointLimits(const RRMatrix& limits);

Method to update the joint limits of the robot in question.

Arguments:

limits The joint limits supplied in amatrix format. Where each rowholds the two extremes of each joint

int SetJointLimits(const RRString& limitsFile);

Method to update the joint limits of the robot in question.

Arguments:limitsFile The joint limits supplied in

a file.Protected Methods

virtual int computeCriteria(constRRMatrix& sols, RRCriteriaValue* critVals);



457

This method is defined in this classand it implements the functionality to

compute the criteria value (that is,the joint range availability) for each joint space options supplied to it.

Arguments:

sols The solutions to be sorted. Each

row of this matrix holds a solutionwith the last element of each rowholding he measure of manipulability of the solution..


Return Value: 0 if all solutions aresingular

-1 if an error occurred incriteria computation.1 if okay.

void calculateRangeAndMedian(const RRMatrix& limits, RRVector& range,RRVector& median);

This method computes the ranges of a joint and its median. Thiscomputation is made every time the joint limits are updated.

Argumentslimits A matrix containing the joint limits

of the robot under consideration.range The computed range of each joint

is stored in this vector.median The computed median of each

joint is stored in this vector.



458

B.6.3. class RRPCMinimizeVelocity : public RRPerformanceCriteria

#include <PerformanceCriteria/PCMinimizeVelocity.hpp>

Public Methods

RRPCMinimizeVelocity(const RRVector& currPos, unsigned int maxNoSols,MINORMAX minOrMax = MINIMIZE, unsigned int weight = 1, const RRString&name = RRString(" "));

Constructor. This class implements aperformance criteria that tends tominimize the joint velocity. Thus,this criteria selects joint options thattend to minimize joint velocities.

Arguments:currPosThis specifies the current

joint position of the robot.The joint velocity for each joint space option is

computed by subtractingfrom currPos.maxNoSols The maximum number of

solutions this performancecriteria will be asked tocompute criteria valuesand rank



RRPCMinimizeVelocity(const RRPCMinimizeVelocity& crit);


virtual ~RRPCMinimizeVelocity();


RRPCMinimizeVelocity& operator=(const RRPCMinimizeVelocity& _crit);


int SetCurrentPosition(const RRVector& currPos);



459

This method sets the state of thecurrent joint position of the robot.

This method should be called everytime before a call to the PickSolutionsmethod. The joint velocity criteriaare computed by comparing to thecurrent joint position of the robot setusing this method.

Arguments:

currPos A vector of size DOF that

specifies the current jointlocation of the robot.


int GetCurrentPosition(RRVector& currPos) const;

This method is used to access thestate of the current joint position of the robot.

Arguments:currPos A vector of size DOF that

returns the current jointlocation of the robot.

Return Value: 1 if successful

0 if unsuccessfulProtected Methods

virtual int computeCriteria(const RRMatrix& sols, RRCriteriaValue* critVals);

This method is defined in this classand it implements the functionality tocompute the criteria value (that is, the joint velocity) for each joint spaceoptions supplied to it. It uses thecurrent joint position to compute the joint velocity for each option.

Arguments:

sols The solutions to be sorted. Eachrow of this matrix holds a solutionwith the last element of each rowholding he measure of manipulability of the solution..

crtiVals The computed criteriavalues and the associated

solution number go in this.This array should be of size equal to the number of rows of sols.

Return Value: 0 if all solutions aresingular-1 if an error occurred incriteria computation.1 if okay.



460

B.6.4. class RRPCMaximizeMOM : public RRPerformanceCriteria

#include <PerformanceCriteria/PCMaximizeMOM.hpp>

Public Methods

RRPCMaximizeMOM(unsigned int maxNoSols, MINORMAX minOrMax =MAXIMIZE, unsigned int weight = 1, const RRString& name = RRString(" "));

Constructor. This class implements aperformance criteria that tends tomaximize the measure of manipulability (MOM). That is, jointoptions that have a higher MOM areranked higher.

Arguments:




RRPCMaximizeMOM(const RRPCMaximizeMOM& crit);


~RRPCMaximizeMOM();


RRPCMaximizeMOM& operator=(const RRPCMaximizeMOM& _crit);Copy operator. Copies all attributesand state.

Protected Methods

virtual int computeCriteria(const RRMatrix& sols, RRCriteriaValue* critVals);



461

This method is defined in this classand it implements the functionality to

compute the criteria value (that is, themeasure of manipulability) for each joint space options supplied to it. Inactuality, the MOM is supplied in the

sols argument as the last element of each row, where each row holds a joint space option. Hence, no realcomputation is performed in this case.

Arguments:

sols The solutions to be sorted. Each

row of this matrix holds a solutionwith the last element of each rowholding he measure of manipulability of the solution..


Return Value: 0 if all solutions aresingular

-1 if an error occurred incriteria computation.1 if okay.



462

B.6.5. class RRPCFusion : public RRBase

#include <PerformanceCriteria/PCFusion.hpp>

Public Methods

RRPCFusion(RRPerformanceCriteria** critArray, unsigned int noCriteria, unsignedint maxNoSols, MINORMAX minOrMax = MAXIMIZE, const RRString& name =RRString(" "));

Constructor. This classimplements a data type for criteriafusion. A set of performancecriteria objects are supplied to thisclass. It uses a weighted sum

technique to first rank all jointspace options based on individualcriteria, and then it combines all of them to come up with an overallranking.

Arguments:critArray This holds a pointer to an

array of performancecriteria objects. Theseobjects constitute the

criteria that have to befused.noCriteria Number of criteria being

supplied in critArray.maxNoSols The maximum number of

solutions this performancecriteria will be asked tocompute criteria valuesand rank

minOrMax Minimize or maximize thecriteria. If minimize, thenthe joint option with the

minimum criteria will be atthe top and vice versa

weight The weight of the criteria.

name The name of the object.

virtual ~RRPCFusion();


int PickSolution(const RRMatrix& solutions, RRCriteriaValue* sortedSols);



463

This method is used to rank a setof joint space options based on

their fused criteria values. Thismethod internally callscomputeCriteria on all theperformance criteria objects andthen fuses the individual rankings.

Arguments:

solutions A matrix whose each row

holds a joint solution. Thelast element of each rowshould hold the measure of manipulability of thesolution.

sortedSols This data type holds theranked joint solutions andtheir corresponding criteriavalues.

Return Value: Number of solutions thatwere non-singular or anegative number indicating

the number of the criteriaduring whose computationan error occurred.

void SetDirection(MINORMAX minOrMax);

This method is used to set whetherthe fused criteria has to bemaximized or minimized

Arguments:

minOrMax MINIMIZE if the criteriahas to be minimized.MAXIMIZE if the criteriahas to be maximized.

MINORMAX GetDirection(void) const;

Method to access whether thecriteria is being maximized orminimized

Arguments:Return Value MINIMIZE if the criteria

is being minimized.MAXIMIZE if the criteriais being maximized.

int SetMaximumSolutions(unsigned int maxNoSolutions);

Method sets the maximum numberof joint space options that will beinput into this criteria forevaluation. This method could havebeen avoided, but is primarily madeavailable for computationalefficiency

Arguments:

maxNoSols The maximum number of joint space options thathave to be evaluated

unsigned int GetMaximumSolutions(void) const;



464

Method accesses the maximumnumber of joint space options that

will be input into this criteria forevaluation. This method could havebeen avoided, but is primarily madeavailable for computationalefficiency

Arguments:

maxNoSols The maximum number of

joint space options thathave to be evaluated

unsigned int GetNoCriteria(void) const;

This method accesses the number of performance criteria objects that areinput into this object.

Return Value: The number of criteriaobjects.

int AddCriteria(RRPerformanceCriteria** crit, unsigned int noCrit);

This method is used to add additionalperformance criteria.

Arguments:crit An array of Performance Criteria

pointers, where each pointer pointsto a performance criteria object.

noCrit No of elements in crit .Return Value: 1 if successful

0 if not

Protected Methods

virtual unsigned int sortSolutions(RRCriteriaValue* critVals, unsigned int noSols);

This method sorts the various criteriavalues and the joint space optionsassociated with them. It utilizes aquick sort to do the sorting. Derived

classes can redefine the sortingfunctionality.

Arguments:

critValsA dual vector of criteriavalues and the joint spaceoptions that has to be

sorted.noSols No of solutions to besorted.

Return Value: The number of the bestsolution.

virtual unsigned int rankSolutions(unsigned int noSols);

This method is called after all theindividual criteria’s are evaluatedand the number of valid solutions isalso determined. This method comesup with the overall ranking of solutions by utilizing the individual

rankings and the weights of thecriteria.

Arguments:noSols No of valid solutions. That

is non-singular solutions.Return Value: The number of the best

solution.



465

B.7. Inverse Dynamics Abstractions

B.7.1. class RRInverseDynamics : public RRBase

Abstract Data Type

#include <InverseDynamics/InverseDynamics.hpp>

Public Methods

RRInverseDynamics(const RRString& linkCGM, const RRString& linkInerita, constRRVector3D& gravity = RRVector3D(0.0, 0.0, 9.8));

Constructor for the abstract classRRInverseDynamics.

Arguments:

linkCGM File whose each rowcontains the location of thecenter-of-gravity and massof each link. The center-of-gravity is expressed in ‘X’,‘Y’, and ‘Z’ coordinates of the local link frames. Thenumber of rows in this filesshould be equal to the DOFof the robot.

linkInertia File containing the inertia’sof each link expressed in

their local coordinateframes. Inertia for each link is expressed as a 3 X 3matrix (or an inertia tensor).The number of inertiatensors in this file should beequal to the DOF of therobot.

gravity The acceleration due togravity expressed in thebase coordinate frame of therobot.

virtual ~RRInverseDynamics();Destructor

virtual const RRVector& GetJointTorques( const RRVector& pos, constRRVector& vel, const RRVector& acc, const RRVector3D& handForce, constRRVector3D& handTorq)= 0;



466

A pure virtual method that definesthe interface for computing the joint

torques based on an input jointposition, velocity, acceleration, andhand forces and torques.

Arguments:

pos The joint position of the

robot at which the torqueshave to be evaluated.

vel The joint velocity of therobot at which the torqueshave to be evaluated.

torq The joint acceleration of therobot at which the torqueshave to be evaluated.

handForce The forces acting at the end-effector of the robot.

handTorq The torques acting at theend-effector of the robot.

Return Value: A vector of size DOFholding the joint torques.



467

B.7.2. class RRIDNewtonEuler : public RRInverseDynamics.hpp

#include <InverseDynamics/InverseDynamics.hpp>

Public Methods

RRIDNewtonEuler(const RRString& DHfile, const RRString& linkCGM, constRRString& linkInerita, const RRVector3D& gravity = RRVector3D(0.0, 0.0, 9.8));

Constructor. This class implementsthe recursive Newton-Euler inversedynamics technique.

Arguments:

DHfile File containing the Denavit-Hartenberg parameters of the robot in question.

linkCGM File whose each rowcontains the location of the

center-of-gravity and massof each link. The center-of-gravity is expressed in ‘X’,‘Y’, and ‘Z’ coordinates of the local link frames. Thenumber of rows in this filesshould be equal to the DOFof the robot.

linkInertia File containing the inertia’sof each link expressed intheir local coordinateframes. Inertia for each link

is expressed as a 3 X 3matrix (or an inertia tensor).The number of inertiatensors in this file should beequal to the DOF of therobot.


~RRIDNewtonEuler();


const RRVector& GetJointTorques( const RRVector& pos, const RRVector& vel,const RRVector& acc, const RRVector3D& handForce, const RRVector3D&handTorque);



468

This method implements thefunctionality for computing the

inverse dynamics solution using therecursive Newton-Euler technique.

Arguments:

pos The joint position of the

robot at which the torqueshave to be evaluated.

vel The joint velocity of therobot at which the torqueshave to be evaluated.

torq The joint acceleration of therobot at which the torqueshave to be evaluated.

handForce The forces acting at the end-effector of the robot.

handTorq The torques acting at theend-effector of the robot.

Return Value: A vector of size DOFholding the joint torques.

void SetToolPoint(const RRVector3D& toolPoint);

This method is used to set the valueof the tool point vector (x,y,z)specified in the coordinate frameattached to the last link. If thismethod is not called, the tool pointvector is considered to be [0, 0, 0].

Arguments:toolPoint The vector holding the X,

Y, and Z coordinates of thetool point.



469

B.7.3. class RRIDLagrange : public RRInverseDynamics.hpp

#include <InverseDynamics/Lagrange.hpp>

Public Methods

RRIDLagrange(int DOF, const RRString& linkCGandMass, const RRString&linkInertiafile, const RRVector3D& gravity = RRVector3D(0.0, 0.0, 9.8));

Constructor. This class implementsan inverse dynamics techniqueproposed by Thomas and Tesar[1982] that is based on Lagrangiandynamics and provides a completedescription of the system

Arguments:

DOF The DOF of the robot whose inversedynamics has to becomputed.

linkCGM File whose each row

contains the location of thecenter-of-gravity and massof each link. The center-of-gravity is expressed in ‘X’,‘Y’, and ‘Z’ coordinates of the local link frames. Thenumber of rows in this filesshould be equal to the DOFof the robot.

linkInertia File containing the inertia’sof each link expressed intheir local coordinate

frames. Inertia for each link is expressed as a 3 X 3matrix (or an inertia tensor).The number of inertiatensors in this file should beequal to the DOF of therobot.


~RRIDLagrange();

Destructor. Deallocates memory.const RRRot3by3* GetGlobalInertiaMatrices(const RRXform* globalTs);



470

This method computes the inertiamatrices of each link with respect to

the base frame of the robot. Thelocal inertia matrices were read infrom a data file during objectcreation.

Arguments:

globalTs An array of global

transformation matrices of the links of the robot. Thesize of this array should beequal to DOF.

Return Value: A pointer to an array of 3 X3 matrices of size DOF thatcontain the global inertiamatrices of the links of therobot.

const RRMatrix* GetIstar(const RRTensor& rotGfunc, const RRTensor&transGfunc);

This method is used to compute the

effective inertia of the system. Thismethod should be called after asuccessful call toGetGlobalInertiaMatrices

Arguments:

rotGfunc A tensor of size 3X3XDOFthat holds the rotational firstorder influence coefficientsof the robot at the desired joint position for whichIstar has to be computed.

transGfunc A tensor of size 3X3XDOFthat holds the translationalfirst-order influencecoefficients of the robot atthe desired joint position forwhich Istar has to be

computed. Thesecoefficients should becomputed for the center of mass of each link.

Return Value: A matrix of size DOF XDOF that contains theeffective inertia of thesystem.

const RRMatrix* GetIstar(const RRXform* globalTs, const RRTensor& rotGfunc,const RRTensor& transGfunc);



471

This method is used to compute theeffective inertia of the system. This

method does not have to be calledafter a call toGetGlobalInertiaMatrices as theglobalTs argument is used to updatethe global inertia matrices.

Arguments:




transGfunc A tensor of size 3X3XDOFthat holds the translational

first-order influencecoefficients of the robot atthe desired joint position forwhich Istar has to becomputed. Thesecoefficients should becomputed for the center of mass of each link.

Return Value: A matrix of size DOF XDOF that contains theeffective inertia of thesystem.

const RRTensor* GetPstar(const RRTensor& rotGfunc, const RRTensor&transGfunc, const RRTensor** rotHfunc, const RRTensor** transHfunc);



472

This method is used to compute theinertia power matrix of the system.

This method should be called after acall to GetGlobalInertiaMatrices.

Arguments:

rotGfunc A tensor of size 3X3XDOF

that holds the rotational firstorder influence coefficientsof the robot at the desired joint position for whichIstar has to be computed.

transGfunc A tensor of size 3X3XDOFthat holds the translationalfirst-order influencecoefficients of the robot atthe desired joint position forwhich Istar has to becomputed. These

coefficients should becomputed for the center of mass of each link.

rotHfunc A pointer to an array of tensor pointers of size DOFthat point to tensorscontaining the rotationalsecond-order influencecoefficients of the robot atthe desired position.

transHfunc A pointer to an array of tensor pointers of size DOF

that point to tensorscontaining the translationalsecond-order influencecoefficients of the robot atthe desired position.

Return Value: A tensor of size DOF XDOF X DOF that containsthe inertia power matrix of the system.

const RRTensor* GetPstar(const RRXform* globalTs, const RRTensor& rotGfunc,const RRTensor& transGfunc, const RRTensor** rotHfunc, const RRTensor**transHfunc);



473

This method is used to compute theinertia power matrix of the system.

This method does not have to becalled after a call toGetGlobalInertiaMatrices as theglobalTs argument is used to updatethe global inertia matrices

Arguments:




transGfunc A tensor of size 3X3XDOFthat holds the translational

first-order influencecoefficients of the robot atthe desired joint position forwhich Istar has to becomputed. Thesecoefficients should becomputed for the center of mass of each link.

rotHfunc A pointer to an array of tensor pointers of size DOFthat point to tensorscontaining the rotational

second-order influencecoefficients of the robot atthe desired position.

transHfunc A pointer to an array of tensor pointers of size DOFthat point to tensorscontaining the translationalsecond-order influencecoefficients of the robot atthe desired position.

Return Value: A tensor of size DOF XDOF X DOF that containsthe inertia power matrix of the system.

int GetAppliedLoadTorques(int linkNo, const RRTensor& rotGfunc, constRRTensor& transGfunc, const RRVector& linkLoad, RRVector& jntTorq);



474

This method computes the jointtorques (or forces for prismatic)

based on a load acting on a link. Itcomputes the result based on thevalues of the first-order influencecoefficients that are supplied asarguments.

Arguments:

linkNo The link at which the link load is

acting. The point of application of this load on a link is taken to be theone for which the translational firstorder influence coefficients(transGfunc) are supplied.


transGfunc A tensor of size 3X3XDOF

that holds the translationalfirst-order influencecoefficients of the robot atthe desired joint position forwhich Istar has to becomputed. Thesecoefficients should becomputed for the center of mass of each link.

linkLoad This is a six dimensionalvector which indicates theload acting on the link

(specified by linkNo). Thefirst three entries of thevector specify the x,y,zforce components. The lastthree entries specify thex,y,z moments

jntTorq A vector of dimension DOFin which the computedtorques are stored.

Return Value: 1 if successful0 if error.

int GetGravityTorques(const RRTensor& rotGfunc, RRVector& gTorq);



475

This method computes the jointtorques (or forces for prismatic)

based on a load acting on the basedon the current value of theTranslational first-order influencecoefficients and link masses. It isassumed that the translational first-order influence coefficients havebeen calculated for point on each link which is at the Center of Mass forthat link. If the coefficients are notabout the center of mass, then theuser should recompute them for thecenter of Mass using the

GetTranslationalGfunctions(...)method in the RRFKVelocity class.

Arguments:

rotGfunc A tensor of size 3X3XDOF

that holds the rotational firstorder influence coefficientsof the robot at the desired joint position for whichIstar has to be computed.

gTorq A vector of dimension DOFin which the computedtorques are stored.


int GetVelocityTorques(const RRVector& jntVel, RRVector& vTorq);

This method computes the jointtorques (or forces for prismatic)based on the current global inertiapower matrices (pstar) and thecurrent joint velocities. The currentstate of the inertia power matrices isused for this computation.

Arguments: jntVel A vector of dimension DOF

that holds the jointvelocities.

vTorq A vector of dimension DOFin which the computedtorques are stored.


int GetAccelerationTorques(const RRVector& jntAcc, RRVector& aTorq);

This method computes the jointtorques (or forces for prismatic)based on the current global inertialmatrix (Istar) and the current jointaccelerations. The current state of the global inertia matrix is used forthis computation.

Arguments:

jntAcc A vector of dimension DOFthat holds the jointaccelerations.

aTorq A vector of dimension DOFin which the computedtorques are stored.


const RRVector& GetJointTorques(const RRVector& pos, const RRVector& vel,

const RRVector& acc, const RRVector3D& handForce, const RRVector3D&handTorque);



476

This method computes the total jointtorque due to joint velocity,

acceleration, and applied loads. Thismethod basically sums up the resultsof all the Get****Torques methodsand should be called after asuccessful call to each of thosemethods.

Arguments:

pos A vector of dimension DOF that

holds the joint positions.vel vector of dimension DOF that holds

the joint velocities.

acc A vector of dimension DOF thatholds the joint accelerations

handForce A vector of dimension 3that holds the end-effectorforces

handTorque A vector of dimension 3that holds the end-effectortorques

Return Value: A vector of size six holding

the joint torques.



477

B.8. Deflection Modeling Abstractions

B.8.1. class RRDeflection : public RRBase

Abstract Data Type

#include <Deflection/Deflection.hpp>

Public Methods

RRDeflection(int DOF, const RRString& linkFlex, const RRString& jointFlex);

Constructor for the abstract classRRDeflection.

Arguments: DOF The DOF of

the robot whose deflectionmodel has to be computed.

linkFlex The file that contains all thelocal flexibility matrices foreach link. Each link flexibility matrix is of size 6X 6 and their total numberis equal to the DOF of therobot.

jointFlex The file that contains thecompliance values for each joint. Compliance for a

joint is expressed as a singlenumber.

virtual ~RRDeflection();

Destructor

virtual int GetFlexibilityMatrix(int linkNo, const RRXform& localTs, RRMatrix&globalFlex) = 0;

This method is used to compute theflexibility matrices for each link.This computation is made using thelocal flexibility matrices that wereread from a file during objectcreation.

Arguments:

linkNo The number of the link for whichthe global flexibility matrix has tobe computed.

localTs The local transformation matrix of link linkNo.

globalFlex A matrix of size 6X6 inwhich the global flexibilitymatrix is stored.




478

virtual const int GetLinkDeflection(int linkNo, const RRVector& linkLoad,RRVector& linkDefl)= 0;

This method is used to compute thedeflection of each link based on agiven link load. This method usesthe current state of the globalflexibility matrix of a link. The stateof a flexibility matrix can be updatedby a call to GetFlexibilityMatrix.

Arguments:linkNo The number of the link for which

the link deflection has to becomputed.

linkLoad A vector of size six thatholds the forces and torquesacting on the link.

linkDefl A vector of size six thatholds the computeddeflection.


virtual const int GetDeflectionDueToLinks(const RRTensor* rotGfunc, constRRVector& deflection)= 0;

A pure virtual method that definesthe interface for computing thedeflection at the end-effector due tolink deflection due to link loads.This method uses the current state of the local link deflection of each link.This local link deflection of each link should be updated with a call toGetLinkDeflection.

Arguments:rotGfunc A tensor of size 3 X 3 X

DOF that contains therotational G functions.

Deflection A vector of size 6 that holdsthe computed totaldeflection at the end-effector due to the links.


virtual const int GetLocalJointDeflection(const RRVector& jointLoads, RRVector& jointDefl)= 0;

A pure virtual method that definesthe interface for computing thedeflection of each joint due toapplied loads at each joint. Thisdeflection is computed bymultiplying the load at a joint by itscompliance.

Arguments:

jointLoads A vector of size DOF thatholds the joint loads. These joint loads can be computedusing any inverse dynamicsformulation.

jointDefl A vector of size DOF thatholds the computeddeflection of each joint.


virtual const int GetDeflectionDueToJoints(const RRMatrix* jacobian, RRVector&endDefl)= 0;



479

A pure virtual method that definesthe interface for computing the

deflection at the end-effector due todeflections at the joints. Thismethod uses the current state of the joint deflections to compute thedeflection at the end-effector. TheJacobian supplied to this methodshould have been computed for the joint position at which the deflectionis being computed.

Arguments:

jacobian A matrix of size 6 X DOF

that contains the Jacobianfor matrix for the end-effector.

endDefl A vector of size 6 that holdsthe computed totaldeflection at the end-effector due to the joints.


virtual const int GetDeflectionDueToJoints(const RRMatrix* jacobian, constRRVector& jointLoads, RRVector& endDefl)= 0;

A pure virtual method that defines

the interface for computing thedeflection at the end-effector due todeflections at the joints. Thismethod first callsGetLocalJointDeflection to computethe deflection at each joint. TheJacobian supplied to this methodshould have been computed for the joint position at which the deflectionis being computed.

Arguments:

jacobian A matrix of size 6 X DOFthat contains the Jacobianfor matrix for the end-effector.

jointLoads A vector of size DOF thatholds the joint loads. These joint loads can be computedusing any inverse dynamicsformulation.

endDefl A vector of size 6 that holdsthe computed deflection of the end-effector.




480

B.9. IODevices Abstractions

B.9.1. class RRKeyboard : public RRBase

#include <IODevices/Keyboard.hpp>

Public Data Members

enum BLOCKMODE {NONBLOCK = 0, BLOCK = 1};

This enumeration defines a data type that can be used for setting the state of akeyboard. If the BLOCKMODE is NONBLOCK, the keyboard can be readasynchronously. That is the program will not wait for a key to be pressed. If theBLOCKMODE is BLOCK, the program will wait till a key is pressed.

Public MethodsRRKeyboard(BLOCKMODE blockMode = BLOCK);

Constructor. The blocking mode isset to BLOCK by default.

Arguments:

blockMode Specify the blocking statusof the keyboard.

~RRKeyboard();

Destructor. Resets the state of thekeyboard to canonical processing of characters.

int GetKeyState(char key);

This method gets the state of aparticular key specified by key.

Arguments:key The key whose sates is desired.Return Value: 1 if key is pressed

0 if key is not pressed

char GetKey(void);

This method returns the key that ispressed. In block mode, this methodwaits till a key is pressed and in non-block it just polls.

Return Value: The key that is pressed.0 if no key is pressed (inNONBLOCK mode)

int SetBlockingMode(enum BLOCKMODE blockMode);

This method sets the blocking modeof the keyboard.

Arguments:blockMode The desired blocking modeReturn Value: 1 if successful

0 if unsuccessfulBLOCKMODE GetBlockMode(void);

This method gets the blocking modeof the keyboard.

Return Value: the BLOCKMODE

int UpdateVector(RRVector& input, const RRVector& deltas, char quitKey =ESC);



481

This method is used to update the

input vector by an amount specified

in the deltas vector. Both the input and the deltas vector should be of the same size. The keys ‘1’ through‘=’ and keys ‘a; through ‘;’ are usedfor positive increments and the keysq through ‘]’ and keys ‘z’ through ‘/’are used for negative increments.The number of keys used depends onthe size of the input vector.

Arguments:

input A vector of size < 23 that has to be

updated based on what key ispressed.

deltas A vector of size < 23 and of thesame size as that of input that holdsthe corresponding delta increments.Every time a relevant key ispressed, a particular element of

input is incremented ordecremented by an amount

specified by the correspondingelement of deltas.

quitKey This key specifies the key that

when pressed will result in areturn value of -3. This returnvalue can be used by the calling

program to take a desired action.Return Value: The element number of

input that was changed.Value will be between 0and size of input

-1 if input was not changed.

-2 if size of input is not thesame as the size of

deltas.-3 if the size of input isgreater than 22.-4 if the quitKey is

pressed.



482

B.10. Controller Abstractions

B.10.1. class RRController : public RRBase

Abstract Data Type

#include <Controller/Controller.hpp>

Public Methods

RRController(const RRString& name);

Constructor. This is the constructorfor this abstract class that defines theinterface for all manual controllers.Interface declaration has yet to beprovided for this class.

Arguments:




483

B.10.2. class RRTeachBall : public RRController

#include <Controller/TeachBall.hpp>

public:

RRTeachBall(char portNo, const RRHandPose& startingHand, const RRHandPose&deltaHand = RRHandPose (0.01, 0.01, 0.01, 0.0001, 0.0001, 0.0001), constRRString& name = RRString(" "));

Constructor. Arguments:

portNo The number of the serialport to which the

TeachBall is connected.startingHand This specifies the starting

hand position. TheTeachBall object modifiesthis hand position everytime the TeachBall is

moved.deltaHand This specifies the amount

by which the startingHand

is changed every time theTeachBall is moved. The

delta’s specified in thisargument are multiplied by

the outputs generated bythe TeachBall to find thenecessary increments.

name Name of the object.~RRTeachBall();

Destructor.

int Initialize(void);

This method opens the serial portand initializes the TeachBall.


int SetDeltaHand(const RRHandPose& deltaHand);



484

This method sets the delta’s that areused to increment the hand vector

ever time the TeachBall is moved.

Arguments:

deltaHand This specifies the amount

by which the startingHand is changed every time theTeachBall is moved. Thedelta’s specified in this

argument are multiplied bythe outputs generated bythe TeachBall to find the

necessary increments.Return Value: 1 if successful

0 if unsuccessful

const RRHandPose& GetDeltaHand(void) const;

This method gets the delta’s that arebeing used to increment the handvector ever time the TeachBall ismoved.

Return Value: The current state of the deltavector.

int GetDeltaHand(RRHandPose& deltaHand) const;

This method gets the delta’s that arebeing used to increment the handvector ever time the TeachBall ismoved.

Arguments:

deltaHand This is used to store thecurrent state of the delta

vector.Return Value: 1 if successful

0 if unsuccessful

int GetCurrentHand(RRHandPose& currentHand, RRVectorI& buttons);This method reads the TeachBalland updates the value of the absolutehand vector and also reads the statusof the buttons.

Arguments:

currentHand This is used to store thecurrent state of the handvector that was altered by

the TeachBall movement.buttons A pointer to an array of

integers of size 8 that is

used to store the status of the buttons. A 0 meansthat a button is off and a

positive value means thebutton is on.


int GetButtonStatus(RRVectorI& buttons);



485

This method reads the TeachBalland updates the status of the buttons.

Arguments:

buttons A pointer to an array of

integers of size 8 that isused to store the status of the buttons. A 0 meansthat a button is off and a

positive value means thebutton is on.


int SetCurrentHand(RRHandPose& currentHand);

This method sets the value of thecurrent hand. This new value of the

current hand is the one that getsaltered every time the TeachBall ismoved. Using this method theTeachBall can be multiplexed tocontrol different devices.

Arguments:

currentHand This argument sets the state

of the current hand.Return Value: 1 if successful

0 if unsuccessful



486

B.11. Utility Abstractions

B.11.1. class RRTimer : public RRBase

#include <Utility/Timer.hpp>

Public Methods

RRTimer() ;

Constructor. Creates a timer objectthat can be used for timing programs

void Start(void);

This method is used to start the

timer. This is similar to starting astop-watch.

void Stop(void);

This method is used to stop the timer.This is similar to stopping a stop-watch.

float ElapsedTime(void);

This method is used to get the timethat elapsed between a call to theStart and Stop methods. This issimilar to reading a stop-watch.

Return Value: The elapsed time in seconds.



487

B.12. Communications Abstractions

B.12.1. class RRTCP : public RRBase

Abstract Data Type

#include <Communications/TCP.hpp>

Public Methods

RRTCP(unsigned short portNo, const RRString& name = RRString(" "));

Constructor. This is an abstract datatype and it specifies the interface forTCP connections.

Arguments: portNo Specifies the port number over

which a TCP connection is made.name The name of the object.

virtual int Initialize() = 0;

Method used to initialize theconnection.

Return Value: 1 if successful-1 if unsuccessful

int Disconnect();

Method to disconnect theconnection.

Return Value: 1 if successful andunsuccessful otherwise.

Unsigned int GetPortNumber() const;

Method to get the port number thatwas specified during construction.

Return Value: The port number beingused for the connection.

int GetSocket() const;

Method to get the number of theTCP socket that is being used for theconnection.

Return Value: The TCP socket number.



488

B.12.2. class RRTCPClient : public RRTCP


Public Methods

RRTCPClient(unsigned short portNo, const RRString& destIP, const RRString&name = RRString(" "));

Constructor. This class is used forcreating a TCP client. The TCPclient initiates communication with aTCP server by connecting to it.

Arguments:

portNo Specifies the port number overwhich a TCP connection is made.

destIP The Internet protocol address of thecompute on which the server towhich the connection to be made is

running.name The name of the object.

int Initialize();

Method used to make the connectionwith the server


int Transmit(char* data, unsigned int length);

Method used to transmit data to theserver. When data is transmittedusing this method, a reply is notexpected from the server.

Arguments:

data A pointer to the data that has to betransmitted.

length The length in bytes of the data thathas to be transmitted.

Return Value: Number of bytes transmitted

-1 if unsuccessfulint Transmit(char* sendData, unsigned int sendLength, char* recvData, unsigned intrecvLength);

Method used to transmit data to theserver. When data is transmittedusing this method, a reply is expectedfrom the server.

Arguments:sendData A pointer to the data that

has to be transmitted.sendLength The length in bytes of the

data that has to betransmitted.

recvData A pointer to a characterarray in which the receiveddata has to be stored.

recvLength The length of the data to bereceived.

Return Value: Number of bytes transmitted0 if unsuccessful



489

B.12.3. class RRTCPServer : public RRTCP


Public Methods

RRTCPServer(unsigned short portNo, const RRString& name = RRString(" "));

Constructor. This class is used forcreating a TCP server. The TCPserver waits and listens till a clientconnects to it.

Arguments: portNo Specifies the port number over

which a TCP connection is made.name The name of the object.

int Disconnect();

Method to disconnect the connection. Return Value: 1 if successful andunsuccessful otherwise.

int Initialize();Method used to wait and listen till aclient connects.


int Receive(char* recvData, unsigned int recvLength);

Method used to receive data from theclient.

Arguments:recvData A pointer to an array in

which the received data is tobe stored.

recvLength The length in bytes of thedata that has to be received.

Return Value: Number of bytes received-1 if unsuccessful

int Reply(char* sendData, unsigned int sendLength);Method used to send a reply to theclient.

Arguments:

sendData A pointer to the data thathas to be sent to the client.

sendLength The length in bytes of thedata that has to be sent.

Return Value: Number of bytes sent-1 if unsuccessful



490

Appendix C

C. Experiments with OSCAR

C.1. Proposed Test Activity

This paper proposes a means of testing the object-oriented software

components being developed at the Robotics Research Group as a part of this

dissertation. The purpose of this activity is two-fold. First, this activity will

provide an environment that will be useful in debugging the software components,

testing their reuse and rapid-prototyping potential, and also realizing their worth

for real-world applications. The second benefit of this activity is that it will

expose future users of the software components to the application domain and

usage of the software. Users will gain information regarding what is available,

where it is available, how to use it, how to get maximum software reuse, and how

to achieve rapid-prototyping with these components. In addition, the users will be

exposed to the development environment (operating system, makefiles, source

code control, editors, and software development guidelines(see Appendix A))[

Silberschatz and Gahin, 1994] [Oram and Talbott, 1995] [Bolinger and Bronson,1995]. This information is imperative to any world class software development.



491

C.2. Desired User Qualifications

There are two areas in which the user has to be proficient. First, the user

should be well versed in object-oriented design and the C++ programming

language. Knowledge about operating systems, parallel execution environments,

and source code management is desired but not needed. Second, the user should

understand the domain of advanced robotics. This includes linear algebra,

generalized kinematics (both forward and inverse), generalized dynamics,

generalized deflection modeling, and performance criteria. In depth

understanding of the domains is not needed, though the key inputs and outputs of each domain should be well understood. A complete understanding of the domain

will be needed if the user intends to add additional functionality to the existing

software components. Most of all, the user should exhibit sound engineering and

design skills. Here are a few suggestions that are necessary to develop reusable

software components:

Be well versed in the C++ programming language and object-oriented design.

Implementation should be less of a challenge. The challenge should be in the

domain analysis and the conceptual design.

When tackling a problem, do not start worrying about implementation details

till you have worked out an analytical design solution.

Think of software components independently of each other. This will let you

design better reusable software classes.

Software components should not be designed for use in a particular

application. For every component think of all possible use-case scenarios and

future reusability support.

While implementing, try to provide two interfaces to each class. The first

interface should be targeted for ease of use while the second should be



492

targeted at maximum computational efficiency. For example, consider the

Matrix class in which the operator * is overloaded for Matrix multiplication.

This method leads to a constructor call that is used to return the product of

two matrices (most compilers will optimize here, but still….). As most

robotics software is executed repeatedly in a loop, it will be beneficial to

provide another interface for multiplying two Matrices. This interface will

eliminate the allocation of Matrix object every time two matrices are

multiplied.

C.3. Software Development Environment

The software development environment has three main components.

These are explained below:

C.3.1. Programming Language

The programming language of choice is C++. Two compilers are

available for source code compiling. The first is the Sun C++ compiler that can

be used to generate executables for the Solaris operating system. Theseexecutables execute on a SUN workstation running Solaris 2.2. The other

available compiler is the GNU C++ cross-compiler for the Motorola 68k family of

processors and the VxWorks operating system from Wind River Systems

[WindRiver Systems, VxWorks Programmer’s Guide]. As the GNU compiler is a

cross-compiler, it is used on the SUN workstation to produce machine code that

can be downloaded to a 68k processor running VxWorks 5.2. Both these

compilers support parameterized data-types (templates) but use different

techniques for template instantiations. The VxWorks development environment

also supports the Tools.h++ library from RogueWave software, the iostreams

libraries from AT&T and the Booch components [RogueWave Software, C++



493

Booch Components] [RogueWave Software, Tools.h++]. The Sun C++ compiler

supports iostreams libraries.

C.3.2. Operating Systems

Source code can be currently compiled using the compilers mentioned

above for the Solaris (using SUN C++) operating system and for VxWorks using

the GNU C++ compiler. The majority of the source code compiles for both

operating systems. Almost all the I/O interfacing code is specific to the VxWorks

operating system and does not compile under Solaris. Applications can be

developed to control either a graphical simulation or a physical robot.

Applications developed for VxWorks can be used for both these purposes

whereas applications developed on the SUN can only be used to control a

simulation.

C.3.3. Source Code Organization

Currently all the source code is placed in the ‘oscar’ account on the SUN

workstation (darkstar.mer.utexas.edu). The source code is organized in differentdirectories based on the domain it belongs to. The absolute path to the source

code is “/export/home/oscar/Research/src.” Under ‘src’ the domains are

partitioned into different directories. This directory structure is graphically shown

in Figure C.1 and a brief description of the directories is listed.



494

src

Communications

Base

Containers

Deflection

Controllers

RobotData

DualArmUtilities

ForwardKinematics

InverseDynamics

IODevices

Math

InverseKinematics

PerformanceCriteria

Utilities

Application

SUNApplication

Demos

VxWorks

SUN

VxWorksAndSUN

VxWorksApplication User Directories

User Directories

Figure C.1: Directory Structure for OSCAR Source Code Organization.

Base: This contains the RRBase class that is the parent of all classes in OSCAR.Communications: This contains source code for inter-process and inter-computer

communication using transmission control protocol (TCP) sockets.

Containers: This contains source code for various container classes, for example

linked lists, etc.

Controllers: Contain the source code for various manual controllers, for example

Teach Ball.

Deflection: Contains classes for generalized deflection modeling.

DualArmUtilities: Contains utility classes that are used to interface and control

the dual-arm (VxWorks specific).



495

RobotData: Contains classes for reading formatted data from files. For example,

DH parameter data.

ForwardKinematics: Contains classes for generalized forward kinematics.

IODevices: Contains classes for various IO devices like serial ports (VxWorks

specific).

InverseDynamics: Contains classes for generalized inverse dynamics of serial

robots.

InverseKinematics: Contains classes for generalized inverse kinematics for serial

robots.

Math: Contains classes for various linear algebra constructs, for example

matrices, vectors, tensors, etc.

PerformanceCriteria: Contains classes for performance criteria and criteria

fusion.

Utilities: Contains source code for utility data types (string) and error checking

source code.

Application: This is the directory in which a user can create and compile an

application that uses OSCAR. Individual sub-directories should be created by

users for better organization.

SUNApplication: This directory should be used to create Solaris specific

applications. Users should create personal directories inside this directory for

their Solaris specific applications.

VxWorksApplication: This directory should be used to create VxWorks specific

applications. Users should create personal directories inside this directory for

their VxWorks specific applications.

Demos: This directory contains completed programs that are used for

demonstrating OSCAR. There are further three sub-directories in this directory.



496

SUN : This directory should contain demonstration programs that just execute

under the Solaris environment.

VxWorks: This directory should contain demonstration programs that just

execute under the VxWorks environment.

VxWorksAndSun: This directory is contained in the Demos directory and should

be used to create demonstration applications that run on both VxWorks and

Solaris.

C.3.4. Source Code Management

All the source code is currently available to any user who logs in as

‘oscar.’ In future this will be replaced by a Source Code Control System (SCCS)

[Bolinger and Bronson, 1995] which will allow users to function from their own

accounts. Besides this, SCCS will provide for version control, serialization of

access to files, and data logging. Compiling of source code is supported by

recursive makefiles [Oram and Talbott, 1995] that are placed in each directory.

Using the same makefile, source code can be compiled for VxWorks or the

Solaris operating system.

C.4. Program Execution Environment

Depending on the type of compiler used, programs can be executed on the

SUN workstation or can be downloaded to the VME rack and can be executed on

the Motorola 68030 processor. On the SUN workstation, the programs can be

executed only in simulation mode. TCP sockets are used between the SUN and

the Silicon Graphics to send joint position commands to the graphical simulation

that executes on the Silicon Graphics. Similarly, a program can be executed on

VxWorks in simulation mode and can use TCP sockets to communicate with the

Silicon Graphics. VxWorks can also execute the same program (with minor



497

changes) for real-time control of the Robotics Research Dual-Arm robot. An

example program that does both simulation and real-time control is located in

“Application/Demos/VxWorks/TeachBall.”

C.5. Experimental Activity

Reiterating, the purpose of the proposed experiments is two-fold. The first

is the testing and usability analysis of the software components and the second is

the training of potential users of this software. Thus, a necessary part of these

experiments is to collect data that can be used to analyze the strengths and

weaknesses of this software architecture and the components itself. This analysis

of OSCAR’s strengths and weaknesses can be made by comparing it to existing

software libraries that allow for robot control program development. Such

libraries do not currently exist at the Robotics Research Group in an organized

manner. Though pieces of independently written C and FORTRAN code do exist.

Software libraries for robot control have been developed by other researchers but

these did not include advanced concepts as generalized kinematics, generalized

dynamics, and performance criteria (see Chapter Two for more details). Thus, in

the proposed experiments, OSCAR will be compared to software libraries the

experimenters have used in the past. In addition, an important hypothesis,

“OSCAR cuts robot control program development time by 50% as compared

to previously existing software environments” will also be tested in this

experiment. To evaluate this hypothesis and to gain a better use-case

understanding of OSCAR, the experimenters are expected to conduct the

described experiments and rank the criteria listed in Table C.1 on a scale of 0 to

10 for each experiment. Each experiment has to be performed once by each team

of experimenters. The experiment will be considered complete when the program

under development is fully coded, tested and its performance satisfies the



498

objective of the experiment. As the experiments progress, new domains of

OSCAR are introduced and the complexity of the experiments also increases.

The last experiment will be different for each team and will involve extending

OSCAR in a robotics area that is of interest to the experimenter.

The software components under OSCAR utilize inheritance as a means of

code reuse. Templateized version of the RRMatrix and RRVector are also

available but it is not functional under VxWorks. The details of the software

component developed as a part of this research is given in Chapter Five and

Appendix B. The software development guidelines that were followed under

OSCAR are detailed in Appendix A. These guidelines should be followed while

conducting the experiments. After conducting each experiment, the experimenter

should fill the evaluation sheet shown in Table C.1. Additional relevant

comments should be also provided at the end of the evaluation sheet. The next

section discusses the experiments that have to be performed. It should be noted

that the complexity of the experiments goes up as the experiments progress.

Environment

Criteria

OSCAR Software Libraries the User

has used in the Past

Ease of Use

Generality

Organization

Time to Code

Time to Test

Table C.1: Evaluation Sheet for Experiments with OSCAR.

Other Comments:



499

C.5.1. Experiment 1

Objective: Gain an understanding of the Vector, Matrix, and Tensor data types.

Procedure: Write a program that creates two matrices and multiplies them. Print

out the result of the multiplication, then transpose of the result, and also the

inverse of the result. Also, learn how to create a tensor and access individual

planes and elements of the Tensor. To gain an understanding of the reuse

potential of the Vector data type, create a new data type that is a vector of size 4

(Vector4). As the size of Vector4 is fixed at compile type, the memory allocation

of Vector4 should take place on the stack. Thus, you will have to override the

memory allocation scheme of Vector if you derive Vector4 from it.

Source Location: Math

Execution Environment: Solaris



500

C.5.2. Experiment 2

Objective: To gain understanding of the RRXform (transformation matrix) data

type, the RRRot3by3 ( 3 by 3 rotation matrix), and the RRHandPose (6 element

long vector) data type.

Procedure: Create some transformation matrices and learn how to set and access

individual elements. Convert these transformation matrices into their equivalent 6

by 1 vector representation. Create two RRHandPose vectors which represent

RPY angles and ZYZ Euler angles respectively. Convert these RRHandPose

vectors into their homogenous transformation matrix representation.

Source Location: Math




501

C.5.3. Experiment 3

Objective: Learn the usage of forward kinematics at the position and Jacobian

level.

Procedure: Create an RRFKPosition object for the DH parameters shown below.

For this robot, then compute the hand position and transformation based on an

input set of joint angles. Also, learn how to access the local transformation

matrices and global transformation matrices of each link. In addition, try to

change the tool-point location and the location of the robot base frame with-

respect-to the world base frame. Similarly, try to create an RRFKJacobian object

and compute the Jacobian for robot in different positions.

# This is a DH parameter file for the 7 DOF Robotics Research Arm The joint type (prismatic or

# revolute) is specified by typing a ‘var' or a ‘VAR’ in its field. That is, if the joint is revolute

# then it will be in the fourth column and if the joint is prismatic it will be in the third column.

# Lengths are in inches and angles in degrees.

# Alpha(i-1) a(i-1) d(i) theta(i)

0.00 0.000 0.00 var # link 0-1

90.0 -4.250 0.00 var # link 1-2

-90.0 4.250 21.5 var # link 2-3

90.0 -3.125 0.00 var # link 3-4-90.0 3.125 21.5 var # link 4-5

90.0 -1.937 0.00 var # link 5-6

-90.0 1.937 12.0 var # link 6-7

Source Location: ForwardKinematics




502

C.5.4. Experiment 4

Objective: Learn the usage of forward kinematics at the velocity and acceleration-

level.

Procedure: Create RRFKVelocity and RRFKAcceleration objects for the robot

whose DH parameters are described in experiment 2. Using these objects, learn

how to compute the rotational and translational G and H functions.

Source Location: ForwardKinematics




503

C.5.5. Experiment 5

Objective: Learn the usage of Generalized Inverse Kinematics Software

Components

Procedure: Write a program that computes the inverse kinematics of any robot

that has a DH parameter-based description. The input to this program should be

the DH parameters and the initial joint configuration of the robot. It should be

noted that there are two separate classes for computing the inverse of 6 DOF and

redundant arms respectively. Your program should automatically create the right

object based on the DH parameter data it reads in. Test your program by reading

an end-effector path from a data file (use classes in FileData). After testing,

implement interactive control of the robot end-effector from the keyboard. For

visualization purposes you will use RoboCad on Silicon Graphics. TCP sockets

will be used to communicate between the SUN workstation (execution

environment) and the SG (simulation environment). Also, learn how to set the

location of the tool point, the location of the robot base frame w.r.t the world

frame. Test your program for the robot whose DH parameters are given in

experiment 4 and also for the Cybo robot arm whose DH parameters are described

below:

# This is a DH parameter file for the 6 DOF Cybo Robot Arm The joint type (prismatic or

# revolute) is specified by typing a ‘var' or a ‘VAR’ in its field. That is, if the joint is revolute


# Lengths are in inches and angles in degrees.


0.0 0.0 17 var # link0-1

-90 0.0 0.0 var # link 1-2

0.0 30 0.0 var # link 2-3

-90 0.0 30 var # link 3-4

90 0.0 0.0 var # link 4-5

-90 0.0 0.0 var # link 5-6

Source Location: ForwardKinematics, InverseKinematics, FileData, Math

Execution Environment: VxWorks, Silicon Graphics



504

C.5.6. Experiment 6

Objective: Learn the usage of sub-structure inverse of redundant robots to achieve

self-motion.

Procedure: Create a partial inverse (RRIKJPartial) object for the robot whose

DH parameters are given below. This RRIKJPartial object by default will lock

the first four joints of the robot and will use the last six for satisfying end-effector

constraints. Self-motions can be achieved by changing the locked value of a

locked joint while solving for the same end-effector constraints. Again, the user

should be able to interactively generate self-motions. A SG will be used in this

experiment for visualization and a TCP connection will be used between the SUN

and the Silicon Graphics.

# This is a DH parameter file for a 10 DOF Fault-Tolerant Robot Arm The joint type (prismatic # or

revolute) is specified by typing a ‘var' or a ‘VAR’ in its field. That is, if the joint is revolute



0.0 0.0 0.0 var # link 0-1

90.0 0.0 0.0 var # link 1-2

-90.0 0.0 393.7 var # link 2-390.0 0.0 0.0 var # link 3-4

-90.0 0.0 354.33 var # link 4-5

90.0 0.0 0.0 var # link 5-6

-90.0 0.0 126.77 var # link 6-7

90.0 0.0 0.0 var # link 7-8

-90.0 0.0 0.0 var # link 8-9

-90.0 0.0 0.0 var # link 9-10

Source Location: ForwardKinematics, InverseKinematics, FileData, Math

Execution Environment: Solaris, Silicon Graphics



505

C.5.7. Experiment 7

Objective: To get familiar with the functionality of the Newton Euler Inverse

Dynamics class.

Procedure: Extend experiment 5 (use DH parameters for the Alpha arm, shown

below) to include the computation of the joint torques as you interactively move

the robot end-effector. As dynamics requires the joint velocity and joint

acceleration information, you will have to compute these using finite differences.

For this experiment, compute the joint torques using Newton Euler

(RRIDNewtonEuler) inverse dynamics formulation. This experiment should

allow for the interactive control of the robot end-effector using the TeachBall.

The DH parameters and the estimated mass parameters and the inertia’s for the

Alpha arm are given below:

# This is a DH parameter file for the 7 DOF Alpha Robot Arm The joint type (prismatic # or revolute) is

specified by typing a ‘var' or a ‘VAR’ in its field. That is, if the joint is revolute



0.0 0.0 156.3 var # link 0-190.0 52.6 0.0 var # link 1-2

90.0 52.6 250.9 var # link 2-3

90.0 40.2 0.0 var # link 3-4

90.0 40.2 250.9 var # link 4-5

90.0 0.0 0.0 var # link 5-6

-90.0 0.0 61.4 var # link 6-7

# This file specifies the coordinates of the C.G. of a link expressed in its local coordinate

# system. Each row specifies the coordinates of the C.G. of the link and its mass. The

# first row is for link 1 and second for link 2 ...

# Coord: X Y Z mass

0.0646008 .00240412 -.119639 38.8583 # link 1

.0260595 -.0388575 -.00348603 25.3161 # link 2

0.0249654 -0.00312822 -0.389549 19.9423 # link 3

0.0620956 0.236611 -0.00704643 14.3786 # link 4

-.0019067 0.0 -0.0777669 5.18914 # link 5

0.0 -0.0697357 0.000767911 6.54798 # link 6

0.0 -0.13148 0.321201 26.2881 # link 7

# This file specifies the inertia matrices for each link of the Alpha robot arm



506

.995849 0.0 0.0 # Inertia Tensor link 1

0.0 0.941168 0.0

0.0 0.0 0.25393

.40201 0.0 0.0 # Inertia Tensor Link 2

0.0 0.383098 0.0

0.0 0.0 0.17758

1.72994 0.0 0.0 # Inertia Tensor Link 3

0.0 1.70551 0.0

0.0 0.0 0.145429


0.0 0.83904 0.0

0.0 0.0 0.0777043

0.0494478 0. 0.0 # Inertia Tensor Link 50.0 0.0477985 0.0

0.9 0.0 0.0137701


0.0 0.0508883 0.0

0.0 0.0 0.0169756


0.0 1.10803 0.0

0.0 0.0 0.66374

Source Location: ForwardKinematics, InverseKinematics, InverseDynamics,

Math

Execution Environment: VxWorks, Silicon Graphics



507

C.5.8. Experiment 8

Objective: To implement a self-contained Inverse Dynamics class that uses

Lagrangian Dynamics (Tesar and Thomas approach).

Procedure: In this experiment you will use the RRIDLagrange class to compute

the joint torques for the Alpha Arm. This experiment is similar to Experiment 7.

The only difference is that you have to use Lagrangian Dynamics and learn how to

get detailed information about the system’s inertial content and the individual

break-up of the joint torques. Thus, using RRIDLagrange, learn how to separately

compute Istar, Pstar, and the individual torque components, e.g., gravity torques,

acceleration torques, etc. It should be noted that the RRIDLagrange class is not a

fully contained inverse dynamics class. The user has to externally create an

RRFKAcceleration class and use that to compute the G and H functions that are

used by RRIDLagrange class. The user can create a self-sufficient inverse

dynamics class (using Tesar and Thomas approach) by encapsulating an

RRFKAcceleration. This should be done as a part of this experiment. The Alpha

arm’s geometrical and mass description is given in Experiment 7.

Source Location: ForwardKinematics, InverseKinematics, InverseDynamics,

Math

Execution Environment: Solaris, Silicon Graphics



508

C.5.9. Experiment 9

Objective: To learn the usage of the generalized deflection modeling software

components.

Procedure: Extend experiment 8 to include deflection modeling for the Alpha

arm. To every joint position that is output from the inverse kinematics object,

apply the generalized deflection model and compute the deflection at the end-

effector. Compensate for this end-effector deflection by adding the deflection to

the desired end-effector position. Based on this new end-effector position,

compute the inverse position solution and then compute the joint torques using

Newton-Euler. This experiment should also allow for interactive execution using

the SG for visualization. The estimated composite compliance (joint and link)

matrices for each link of the Alpha arm are given below:

# This file specifies the compliance matrices for the Alpha manipulator. Each matrix

# is 6x6.

# Joint-Link 1 compliance matrix4.76797e-09 -1.29363e-11 1.79584e-11 4.77269e-10 -2.65275e-09 -1.16114e-09

-1.29363e-11 3.66306e-09 1.23339e-09 -4.63556e-09 5.83829e-11 -1.7344e-10

1.79584e-11 1.23339e-09 1.22997e-09 -1.78723e-09 1.71979e-10 -9.23178e-11

4.77269e-10 -4.63556e-09 -1.78723e-09 0.0 0.0 0.0

-2.65275e-09 5.83829e-11 1.71979e-10 0.0 0.0 0.0

-1.16114e-09 -1.7344e-10 -9.23178e-11 0.0 0.0 0.0

# Joint-Link 2 compliance matrix

2.32974e-09 0.0 0.0 0.0 0.0 0.0

0.0 6.39137e-08 0.0 0.0 0.0 1.74227e-07

0.0 0.0 6.39137e-08 0.0 -1.74227e-07 0.0

0.0 0.0 0.0 8.23119e-07 0.0 0.0

0.0 0.0 -1.74227e-07 0.0 6.37254e-07 0.0

0.0 1.74227e-07 0.0 0.0 0.0 6.37254e-07


7.09771e-09 -1.29363e-11 1.79584e-11 4.77269e-10 -2.65275e-09 -1.16114e-09

-1.29363e-11 6.75768e-08 1.23339e-09 -4.63556e-09 5.83829e-11 1.74054e-07 1.79584e-11 1.23339e-09 6.51437e-08 -1.78723e-09 -1.74055e-07 -9.23178e-11

4.77269e-10 -4.63556e-09 -1.78723e-09 8.23119e-07 0.0 0.0

-2.65275e-09 5.83829e-11 -1.74055e-07 0.0 6.37254e-07 0.0

-1.16114e-09 1.74054e-07 -9.23178e-11 0.0 0.0 6.37254e-07


2.73687e-08 -8.49384e-09 -4.0542e-10 -2.19863e-09 -5.01211e-10 6.76225e-08



509

-8.49384e-09 7.15481e-09 -2.04081e-10 1.12966e-10 4.76033e-10 2.54034e-08

-4.0542e-10 -2.04081e-10 1.70048e-08 2.70558e-08 -1.39157e-08 7.88967e-10

-2.19863e-09 1.12966e-10 2.70558e-08 0.0 0.0 0.0

-5.01211e-10 4.76033e-10 -1.39157e-08 0.0 0.0 0.0-6.76225e-08 2.54034e-08 7.88967e-10 0.0 0.0 0.0


4.32974e-09 0.0 0.0 0.0 0.0 0.0

0.0 3.39137e-08 0.0 0.0 0.0 1.74227e-07

0.0 0.0 5.39137e-08 0.0 -1.74227e-07 0.0

0.0 0.0 0.0 3.23119e-07 0.0 0.0

0.0 0.0 -1.74227e-07 0.0 4.37254e-07 0.0

0.0 1.74227e-07 0.0 0.0 0.0 4.37254e-07


7.09771e-09 -1.29363e-11 1.79584e-11 4.77269e-10 -2.65275e-09 -1.16114e-09

-1.29363e-11 6.75768e-08 1.23339e-09 -4.63556e-09 5.83829e-11 1.74054e-07

1.79584e-11 1.23339e-09 6.51437e-08 -1.78723e-09 -1.74055e-07 -9.23178e-114.77269e-10 -4.63556e-09 -1.78723e-09 8.23119e-07 0.0 0.0

-2.65275e-09 5.83829e-11 -1.74055e-07 0.0 6.37254e-07 0.0

-1.16114e-09 1.74054e-07 -9.23178e-11 0.0 0.0 6.37254e-07


2.73687e-07 -8.49384e-09 -4.0542e-10 -2.19863e-09 -5.01211e-10 -6.76225e-08

-8.49384e-09 7.15481e-08 -2.04081e-10 1.12966e-10 4.76033e-10 2.54034e-08

-4.0542e-10 -2.04081e-10 1.70048e-07 2.70558e-08 -1.39157e-08 7.88967e-10

-2.19863e-09 1.12966e-10 2.70558e-08 1.25555e-09 0.0 0.0

-5.01211e-10 4.76033e-10 -1.39157e-08 0.0 1.25555e-09 0.0

-6.76225e-08 2.54034e-08 7.88967e-10 0.0 0.0 1.25555e-09

Source Location: Deflection, InverseKinematics, InverseDynamics, Forward

Kinematics Execution Environment: Solaris, Silicon Graphics



510

C.5.10. Experiment 10

Objective: To design and implement software components in your area of interest

and expertise.

Procedure: To be discussed with Dr. Hooper and Dr. Tesar.



511

C.6. User Qualification Assessment

User qualification assessment was necessary for normalizing the results of

the experiments based on user experience, aptitude, and motivation. A measure

of the experimenter qualification and aptitude was achieved by consultation with

the experimenter’s academic supervisor and by monitoring their progress over the

course of the experiments. To gauge user qualification, a survey was performed

that measured four things. These were:

Experience with object-oriented programming using C++.

An understanding of the domain of advanced robotics.

Experience with the software system the experimenter is comparing to

OSCAR.

How closely does the compared software system satisfy operational software

needs of advanced robotics (that is, the main purpose of OSCAR).

The survey used for measuring the user qualifications is shown below:

On a scale of 1 to 10, how would you gauge your experience with the software

system you are comparing OSCAR with, to programming in a C, C++ type

environment (use experience level prior to the beginning of the experiments)?

C/C++ Type _________ Compared Software System ____________

How many Robotics related undergraduate courses have you had? _________

How many Robotics related graduate courses have you had? ______________

How many Linear Algebra math courses have you had? ______________

What is the primary software system you were comparing OSCAR too (give

details)? _______________________________________________________

_________________________________________________________________

_________________________________________________________________

_________________________________________________________________



512

C.7. Experiment Results

C.7.1. Experimenter A

Experiment 1:

Environment

Criteria

OSCAR Software Libraries the User has

used in the Past

Ease of Use 8 10

Generality 8 9

Organization 10 10

Time to Code 3 hour 0.67 hours

Time to Test 1 hour 0.67 hoursComments: Easy implementation. A possible bug when copying columns in the

RRMatrix class.

Experiment 2:

Environment

Criteria


used in the Past

Ease of Use 8 10

Generality 9 9

Organization 8 10Time to Code 3 hour 0.25 hours

Time to Test 1 hour 0.25 hours

Comments: More documentation needed.

Experiment 3:

Environment

Criteria


used in the Past

Ease of Use 7 5

Generality 8 5



513

Organization 10 5

Time to Code 5 hour 10 hours

Time to Test 1 hour 1 hourComments:

Experiment 4:

Environment

Criteria


used in the Past

Ease of Use 8 5

Generality 9 5

Organization 10 5


Time to Test 1 hour 1 hourComments:

Experiment 5:

Environment

Criteria


used in the Past

Ease of Use 7 7

Generality 10 4

Organization 10 5

Time to Code 10 hours 10 hoursTime to Test 1 hour 1 hour

Comments:

Experiment 6:

Environment

Criteria


used in the Past

Ease of Use 9 5

Generality 8 5



514

Organization 9 N/A


Time to Test 1 hour 1 hourComments: Easy to use (took a while to figure out and then was straight). If

documentation had been generated earlier, experiments would have taken less

time.

Experiment 7:

Environment

Criteria


used in the Past

Ease of Use 9 5

Generality 9 5Organization 9 N/A

Time to Code 8 hours 50 hours

Time to Test 1 hour 40 hours

Comments: Experiment did not work on VxWorks.

Experiment 8:

Environment

Criteria


used in the Past

Ease of Use 8 3Generality 8 3

Organization 10 3



Comments: Since background in Lagrangian approach to inverse dynamics was

not sound, it took a little while to get started. New documentation has helped

considerably.

Experimenter Questionnaire

Experimenter Name: _____A____ _



515


system you are comparing OSCAR with, to programming in C/C++ type


C/C++ Type ____7____ Compared Software System _____5_____

How many Robotics related undergraduate courses have you had? __ 0____

How many Robotics related graduate courses have you had? _____1_______

How many Linear Algebra math courses have you had? ______2_______


details)?

Mainly my experience in software systems for robotics applications is related

to Matlab. Basically I developed small "objects" to calculate Inverse/Forward

kinematics and used "spatial notation" taught by Dr. Sreenivasan. One of the

most noticeable limitations of Matlab was its lack of support for 3-

Dimensional matrices/Tensor like objects. Although, different files

corresponded to different, independent objects, they were not quite modular,

that is, corrections/modifications in an object had to be propagated

"propagated" manually in other files.

Averaged Evaluation Data

Environment

Criteria


used in the Past

Ease of Use 8 6.25

Generality 8.50 5.63

Organization 9.67 6.33

Time to Code 3.47 10

Time to Test 0.37 0.31

C.7.2. Experimenter B

Experiment 1:



516

Environment

Criteria


used in the Past


Organization 10 10



Comments:

Experiment 2:

Environment

Criteria


used in the PastEase of Use 8 10

Generality 9 9

Organization 8 10



Comments: More documentation needed.

Experiment 3:

EnvironmentCriteria

OSCAR Software Libraries the User hasused in the Past

Ease of Use 7 5

Generality 8 5

Organization 10 5


Time to Test 1 hour 1 hour

Comments:



517

Experiment 4:

EnvironmentCriteria OSCAR Software Libraries the User hasused in the Past

Ease of Use 8 5

Generality 9 5

Organization 10 5



Comments:

Experiment 5:

Environment

Criteria


used in the Past

Ease of Use 7 7

Generality 10 4

Organization 10 5



Comments:

Experiment 6:

Environment

Criteria


used in the Past

Ease of Use 9 5

Generality 8 5

Organization 9 5



Comments: Easy to use (took a while to figure out and then was straight). If

documentation had been generated earlier, experiments would have taken lesstime.



518

Experiment 7:


Ease of Use 9 5

Generality 9 5

Organization 9 N/A



Comments: Experiment did not work on VxWorks.

Experiment 8:

Environment

Criteria


used in the Past

Ease of Use 8 3

Generality 8 3

Organization 10 3



Comments:

Experiment 10:

Environment

Criteria


used in the Past

Ease of Use 9 5

Generality 9 2

Organization 10 4


Time to Test 180 hours 500 hours

Comments: In general all classes have rapid-prototyping capability and for this

reason they are quite extensible. Adding short examples on how to use a class (inthe appendix) would give a stronger reference to the programmer, especially if

he/she is novice in the field.



519


Experimenter Name: ___B _ On a scale of 1 to 10, how would you gauge your experience with the software



C/C++ Type ___8_____ Compared Software System ______4_____

How many Robotics related undergraduate courses have you had? ___0_____

How many Robotics related graduate courses have you had? _______5______

How many Linear Algebra math courses have you had? _______1______


details)?

I took S.V’s class "Robot Dynamics" last year. In that class we wrote code

that solved the inverse kinematics, forward and inverse dynamics. Our group

used Mathematica which by the forward dynamics program had become

unmanageable (too slow, no generality, error prone). At the time, I had little

experience with Mathematica. On the other hand, I have programmed with

OSCAR before. So I am more experienced.


Environment

Criteria


used in the Past

Ease of Use 8.11 6.11



Time to Code 3.47 10.0Time to Test 0.37 0.31



520

C.7.3. Experimenter C

Experiment 1:

Environment

Criteria


used in the Past

Ease of Use 10 8

Generality 8 7

Organization 7 7

Time to Code 8 8

Time to Test 8 8

Comments:

Experiment 2:

Environment

Criteria


used in the Past

Ease of Use 8 9

Generality 8 7

Organization 8 9

Time to Code 7 8

Time to Test 7 8

Comments:

Experiment 3:

Environment

Criteria


used in the Past

Ease of Use 7 4

Generality 8 4

Organization 7 6

Time to Code 6 3

Time to Test 6 3Comments:



521

Experiment 4:


Ease of Use 7 4

Generality 8 4

Organization 8 6

Time to Code 8 2

Time to Test 8 2

Comments:

Experiment 5:

Environment

Criteria


used in the Past

Ease of Use 5 4

Generality 8 5

Organization 7 6

Time to Code 4 2

Time to Test 4 5

Comments:

Experiment 6:

Environment

Criteria


used in the Past

Ease of Use 4 2

Generality 8 4

Organization 6 5

Time to Code 3 2

Time to Test 3 2

Comments:



522

Experiment 7:


Ease of Use 7 5

Generality 8 6

Organization 8 7

Time to Code 3 4

Time to Test 3 3

Comments:

Experiment 8:

Environment

Criteria


used in the Past

Ease of Use 6 4

Generality 8 5

Organization 8 5

Time to Code 3 2

Time to Test 3 2

Comments:


Experimenter Name: ___C _




C/C++ Type ___1____ Compared Software System ______8_____


How many Robotics related graduate courses have you had? ______3_______

How many Linear Algebra math courses have you had? ______1_______


details)?



523

Matlab - a mathematical package that I have used to perform robot

simulations.


Environment

Criteria


used in the Past


Generality 8.0 5.25


Time to Code 4.25 5.875




524

C.7.4. Experimenter D

Experiment 1:

Environment

Criteria


used in the Past

Ease of Use 8 9

Generality 9 9

Organization 9 3

Time to Code 8 2

Time to Test 9 1

Comments: All comparisons of this and other five experiments are made among

OSCAR and the symbolic manipulation language, REDUCE, environment.

REDUCE is supposedly an interactive environment. Although time-consuming, it

is possible to write small program modules in REDUCE which can later be

combined to create a "structured" program.

Experiment 2:

Environment

Criteria


used in the Past

Ease of Use 8 6

Generality 8 8Organization 9 2

Time to Code 9 1

Time to Test 10 0

Comments:

Experiment 3:

Environment

Criteria


used in the Past

Ease of Use 7 5


Time to Code 9 2

Time to Test 9 1

Comments:



525

Experiment 4:


Ease of Use 8 6

Generality 10 5

Organization 9 4

Time to Code 9 3

Time to Test 10 2

Comments:

Experiment 5:

Environment

Criteria


used in the Past

Ease of Use 7 3

Generality 10 2

Organization 10 2

Time to Code 7 2

Time to Test 8 3

Comments: Since documentation is not available, it is getting harder to use

programs. With a little documentation, it would be possible to get to know the

inside of the generalized inverse (Pseudo inverse, weighted pseudo inverse which

I know have already been coded).

Experiment 6:

Environment

Criteria


used in the Past

Ease of Use 7 3

Generality 9 3

Organization 9 3Time to Code 6 3

Time to Test 7 2

Comments: Here is the perfect object, RRIKJPartial!



526


Experimenter Name: ___D _ On a scale of 1 to 10, how would you gauge your experience with the software



C/C++ Type ___3____ Compared Software System ______4_____




What is the primary software system you were comparing OSCAR with (give

details)?

Symbolic manipulation language REDUCE. Had numerical built-in functions

too. Interactive environment but allows structured programming. Hard to

program though due to lack of debugging environment. REDUCE is more

comparable to MAPLE, less fancier than Mathematica (no graphic

environment). One advantage is however is that the built-in functions are

available for modification and a considerable amount of source code is

available for purposes.


Environment

Criteria


used in the Past


Generality 9.0 5.5

Organization 7.33 2.83Time to Code 2.16 8.0




527

C.7.5. Experimenter E

Experiment 1:

Environment

Criteria


used in the Past

Ease of Use 8 9

Generality 9 9

Organization 4 8

Time to Code 1 hour .05 hours

Time to Test .1 hour 0 hours

Comments: All experiments are compared to algorithms developed by me in C++

independently of OSCAR, Mathematica, and Matlab.

High performance means that calculations were simple enough to see no

difference. The time to code will vary widely on the completeness of the Vecor4

class. Completion of assignment was not difficult. Inline or no? Which inverse

to use? Which base class operator can be overridden to improve efficiency? Now

that a Vector4 class exists, is it my responsibility to add constructors to classes

that might want to be created from a Vector4? Only programs for comparison are

Mathematica, Matlab, MathCad, and the like. Not very good. Maybe a good idea

for future is to include experiments with timers, so various coding methods could

be tested for efficiency.

Experiment 2:

Environment

Criteria


used in the Past

Ease of Use 8 4


Time to Code 0.5 hours 0.5 hours

Time to Test 0.1 hour 0.1 hour



528

Comments: OSCAR only knows that RRXform is a 4 X 4 matrix. Since size of

matrix is known, much can be done more efficiently. However, if I have a

different type of a 4 X 4 matrix, I have to make mine a descendant of RRXform or

rewrite a bunch of stuff. I suggest that first a Matrix4X4 class be creates, then

RRXform be made a descendant of this class. So if I make an RRFoo ( a 4 X 4

matrix) there is an elegant place to develop this class. Also, should there be some

sort of clean function that can be run that turns very small numbers to zero to

avoid mathematical problems and produce cleaner presentation.

Experiment 3:

Environment

Criteria


used in the Past

Ease of Use 8 5

Generality 10 8

Organization 7 7

Time to Code 1.5 hours 4 hours

Time to Test 0.25 hours 1 hour

Comments: Generality is actually quite good. Though generality is still very

dependent on the code used. Several tricks were pointed out that I would not have

thought. Future documentation should contain ideas and strategies for

generalization. The tool point defaults to [0, 0, 0] (at least thats what I get). Why

does it not default to a point coinciding with the end of link six, since all is

known. I need to spend more time here understanding exactly what gets updated

when joint angles change. Shouldn’t there be a way to set the tool point from a

HandPose and a transform matrix?



529

Experiment 4:


Ease of Use 9 4

Generality 10 6

Organization 7 4


Time to Test 0.25 hours 1 hour

Comments: Time to code would have been even less if not for a small spelling

error (in OSCAR). At some time in the future, it might be a good idea to improve

the print output options of the software, a low priority suggestion.

Experiment 5:

Environment

Criteria


used in the Past

Ease of Use 8 4

Generality 10 10

Organization 7 4



Comments: A future implementation of the experiment should contain a joint

limit file. Had trouble figuring out how to change the tool-point without changing

the DH file. I am sure a lot of this will be more clear and less time consuming

when your thesis and the description of functions is complete. Right now there

just is not enough time to track down the quirks of all the functions. Most of the

time to program is in finding names of function argument types , etc.



530

Experiment 6:


Ease of Use 5 4

Generality 10 10

Organization 5 5


Time to Test 0.5 hours 8 hours

Comments: Primary frustration resulted from the fact that the fault-tolerant robot

does not perform well under default conditions. Programming time would have

been much shorter if, 1) a different robot was used, 2) knowledge that the first 3

joints should not be locked, or 3) choices was made to build a less robust set of

code. The function catalog would be very handy at this point- yes I know its

coming.

Experiment 7:

Environment

Criteria


used in the Past

Ease of Use 8 6

Generality 10 8

Organization 7 4


Time to Test 0.1 hour 8 hours

Comments: Lack of experience with the makefile caused some delays. this could

be fixed with a better knowledge of its use and importance. RRString seems to be

a bit lame as to its purpose for existing. When should it be used. Excellent

simplicity in coding to use both RRIDNewtonEuler and the RRTeachBall. Main

ease problems arose from using VxWorks.



531

Experiment 8:


Ease of Use 6 4

Generality 9 4

Organization 5 3


Time to Test 0.5 hours 8 hours

Comments: RRIDNewtonEuler is complete bur RRIDLagrange is not. It seems

like a good idea to keep all Inverse Dynamics algorithms using the same interface.

the one we built for the exp ‘RRIDLagrangecomplete’ with certain functions from

RRIDLagrange is way too slow at this point (example, PStar). Granted this is

tough calculation. It is obvious that a close look needs to be made of all the

Inverse Dynamics to ensure speed, accuracy, performance, and executability. A

list of what current areas of OSCAR that are considered robust and which are not

seems like a good idea. Also, begin enforcing revision documentation, so large

revisions are okay.

Experiment 10:

Environment

Criteria


used in the Past

Ease of Use 6 4

Generality 8 4

Organization 8 4


Time to Test still test 20 hours

Comments: No problems for an experienced user. Startup needs to be simplified

- a keyboard check can be added for more robust operation. Also, work can be

done to make robot work even for people who try to wreck it. Goal is still to

make more robust -then implement. Functions developed for this particular



532

object into OSCAR - Bit manipulation classes and dominant method for

RRHandPose, etc.


Experimenter Name: ___E _


system you are comparing OSCAR with, to programming in a C, C++ type


C/C++ Type _____4___ Compared Software System ______2_____ How many Robotics related undergraduate courses have you had? ___0_____




details)?

C++ from scratch. If I was to complete the same experiments, without the use

of OSCAR, how would they compare. Experiments one and two were

compared to Mathematica.


Environment

Criteria


used in the Past




Time to Code 0.466 10.0Time to Test 0.0613636 1.093181818



533

C.7.6. Experimenter F

Experiment 1:

Environment

Criteria


used in the Past

Ease of Use 9 10

Generality 10 9

Organization 9 10

Time to Code 1.5 hours 0.15 hours


Comments: The math classes structure provided in OSCAR is an excellent

starting point. The Vector and Matrix classes make it easy to do basic linear

algebra computations while the more specific derived classes are extremely useful

as well. The matrix class could have more comments in the code.

Experiment 2:

Environment

Criteria


used in the Past

Ease of Use 9 10


Time to Code 1 hour 0.15 hour

Time to Test 1 hour 0.15 hour

Comments: The robotics specific Xform, rotation, and handpose classes work

well and are very easy to use.

Experiment 3:

Environment

Criteria


used in the Past


Organization 9 8





534

Comments: Forward Kinematics at the position, velocity, and acceleration-level

is simple to use and fairly straight forward. OSCAR at this time provides all the

basics in the area and can easily be expanded as the need for more specialized

modules arises.

Experiment 4:

Environment

Criteria


used in the Past

Ease of Use 9 9

Generality 10 9

Organization 9 8



Comments:

Experiment 5:

Environment

Criteria


used in the Past

Ease of Use 8 9

Generality 10 9

Organization 8 9



Comments: Inverse Kinematics is easy to use once the user figures out how the

software components are structured. The files in this directory could especially

benefit from a readme file outlining the overall layout of the inverse kinematics.



535

Experiment 6:


Ease of Use 8 9

Generality 10 9

Organization 9 9



Comments: This class took me awhile to understand and debug. Most of the

problems come from not knowing which robot joints to lock. Overall, this class is

about as easy to use for this complex inverse kinematics.

Experiment 7:

Environment

Criteria


used in the Past

Ease of Use 8 9

Generality 10 9

Organization 9 9



Comments: A lot of the debug time was spent trying to figure out why

RRIDNewtonEuler would not run under VxWorks. This problem was not solved

and will need to be fixed in the future. Other than that, the class performed well

and was easy to use.

Experiment 8:

Environment

Criteria


used in the Past

Ease of Use 8 9

Generality 10 9

Organization 9 9Time to Code 3.5 hours 20 hours


Comments: This class we wrote for this experiment nicely incorporates the

RRIDLagrange and RRFKAcceleration classes. Once again, a problem presented



536

itself when trying to use VxWorks. Also, the Pstar calculations take so much

time that this method is practically worthless for real-time use. I have not written

a great deal of new code. However, I have been working on updating old code,

etc. Overall, OSCAR has provided an excellent structure for writing robotics

code.


Experimenter Name: ___F _




C/C++ Type _____1___ Compared Software System ______9 _____





details)?

Matlab. I have written a lot of robotics related code in Matlab and am quite

familiar with all aspects of Matlab programming.

compared to Mathematica.


Environment

Criteria


used in the Past


Generality 10 9

Organization 8.875 9Time to Code 2.48 10.0

Time to Test 3.398692 3.960784314



537

C.7.7. Experimenter G

Masters Thesis Using OSCAR:

Environment

Criteria


used in the Past

Ease of Use 6 4

Generality 9 5

Organization 8 5

Time to Code 9 1

Time to Test 5 2


Experimenter Name: ___G _




C/C++ Type _____5__ Compared Software System ______5_____

How many Robotics related undergraduate courses have you had? ____0___

How many Robotics related graduate courses have you had? _________3____

How many Linear Algebra math courses have you had? __________2___


details)?

Numerical Recipes in C. This is a set of C routines that can be used for

mathematical calculations.



538

C.7.8. Experimenter H

Experiment 1:

Environment

Criteria


used in the Past

Ease of Use 8 8

Generality 8 8

Organization 8 8

Time to Code 1 hour 1 hour


Comments: For this simple experiment, there isn’t a lot of difference between C

and C++

Experiment 2 :

Environment

Criteria


used in the Past

Ease of Use 8 8

Generality 8 8

Organization 8 8



Comments: In this case, I am comparing OSCAR to existing C tools I have foedoing these type of transformations. Without these C tools, the score would be

more like this:

Environment

Criteria


used in the Past

Ease of Use 8 2

Generality 8 5

Organization 8 5





539

Experiment _3:


Ease of Use 8 8

Generality 8 8

Organization 8 8



Comments: In this case, I am comparing OSCAR to existing C tools I have for

doing for forward kinematics. Without these C tools, the score would be more

like this:

Environment

Criteria


used in the Past

Ease of Use 8 2

Generality 8 5

Organization 8 5



Experiment _4:

EnvironmentCriteria


Ease of Use 8 8

Generality 9 7

Organization 8 8




doing forward kinematics. Without these C tools, the score would be more like

this:



540

Environment

Criteria


used in the Past


Organization 8 5



Experiment _5:

Environment

Criteria


used in the PastEase of Use 8 8

Generality 9 8

Organization 8 8




doing inverse kinematics. Without these C tools, the score would be more like

this:

EnvironmentCriteria


Ease of Use 8 2

Generality 9 5

Organization 8 5





541

Experiment _6:


Ease of Use 8 6

Generality 9 6

Organization 8 6





this:

Environment

Criteria


used in the Past

Ease of Use 8 2

Generality 9 5

Organization 8 5



Experiment _7:

Environment

Criteria


used in the Past

Ease of Use 8 8

Generality 8 8

Organization 8 8


Time to Test 2 hours 2 hoursComments: In this case, I am comparing OSCAR to existing C tools I have for


this:



542

Environment

Criteria


used in the Past


Organization 8 5




Experimenter Name: ___ H _




C/C++ Type ____3.5___ Compared Software System _____8.5 _____

How many Robotics related undergraduate courses have you had? ____1____

How many Robotics related graduate courses have you had? ________3_____



details)?

I am comparing OSCAR to the C programming environment we have had in

the Robotics Research Group for the last 8 years. My experience in the C

language began in 1982 with a Data Structures in C class. I have since used C

in a number of courses and have written 25,000 lines of C code. I also have

programming experience and training in Pascal, FORTRAN, Basic, Machine

Code (68000, Z80), lisp, FORTH, STOIC, and HyperCard. Basically, the

only relevant C software library I’ve used in the past is math.h



543


Environment

Criteria


used in the Past

Ease of Use 8 7.7



Time to Code 7.33 10.0




544

Appendix D

D. Class Libraries for 3D Procedural Modeling

D.1. Introduction

The purpose of this project was to develop object-oriented libraries that

would assist the applications developer in generating and rendering various 3D

shapes. The goal as specified was to provide a class structure that would allow

the creation of various 3D shapes like cones, cylinders, disks, etc. Other desired

capability of these libraries was to provide the user with various rendering options

(WIREFRAME, SMOOTH, FACETED) and shaded surface options (INSIDE,

OUTSIDE, BOTHSIDE). In addition, an environment had to be provided in

which the user defined scene could be rendered. Also, to these graphics specific

classes, other support classes, like container classes were also to be provided.

After completion of these libraries it was required to develop an application that

demonstrated the use of these libraries. This software was to be developed on a

Silicon Graphics UNIX workstation using the GL libraries. These libraries are

now also available on Windows NT using OpenGL.The following paragraphs describe the class structure of these libraries.

The individual classes, their interface, connectivity, and usage is described below.



545

Overall, 5400 lines of C++ code was written and a 800 line application was

developed using these libraries.

D.2. Mathematical Classes

D.2.1. Class Matrix

This class was imported from National Institute of Health Class Library

(NIHCL) collection. Various changes were made to this class, methods were

added and some bugs were fixed. The class implements the Matrix data type and

is fairly intuitive. Methods for inversion, determinant calculation, and

multiplication were re-implemented for speed and accuracy. Along with the

Matrix class the classes MatrixCol, and MatrixRow are declared. These classes

are used to access specific rows and columns of a Matrix. The interface to this

class is present in the header file Rmath.h (see Section D.5.1).

D.2.2. Class TransformMatrix : public Matrix

This class was derived from the Matrix class and basically implements a 4

by 4 homogenous transformation matrix. The purpose of the inheritance was to

achieve restriction and extension. The restriction was achieved by limiting the

Matrix class to 4 by 4 and the extension was achieved by redefining the methods

for multiplication (for speed ) and also by adding methods which would convert a

TransformMatrix into its Euler angle or Fixed angle representation. The

declaration of this class is specified in Rmath.h (see Section D.5.1).

D.2.3. Class Vector

This class implements an abstraction for a one dimensional array. It has

methods for multiplication of the vector with matrices, etc. The declaration of

this class is specified in the Rmath.h file (see Section D.5.1).



546

D.2.4. Class Tensor

This class implements a 3D vector and is essentially an array of matrices.Methods for this class allow the user to access elements, rows, columns, or

matrices from this 3D vector. The declaration of this class is specified in the

Rmath.h file (see Section D.5.1).

D.3. Geometry Related Classes

These classes implement geometric primitives that form the basic

primitives of a geometric modeling system. The classes implemented are Point

and Vector3D.

D.3.1. Class Point

This class implements an abstract data type that specifies a 3D point in

space. Various homogenous transformations can be applied to these points.

These include translation, scaling, and rotation about any desired axis. A point

can also be extruded along a specified vector for a certain length. The class

declaration for Point is given in the file Draw.h ( see Section D.5.2).

D.3.2. Class Vector3D : public Vector

This class Vector3D is implemented as an inheritance of the Vector class.

This class is a restriction and an extension of the Vector class. The restriction is

applied by constraining the Vector class to length three. The extension is applied

by adding methods for calculating the cross-product, dot product, normals, etc.

The class declaration is given in the Draw.h file (see Section D.5.2).



547

D.3.3. Class Polygon

This class implements a basic drawing primitive. The input parameter tothis class is an array of points. These points are used to generate a polygon. The

normal is calculated based on the points supplied. To create a polygon whose

normal faces outside (e.g., coming out of the plane of the towards the user), the

points should be supplied in counter-clockwise direction. This is illustrated in

Figure D.1.

Point 1

Point 2

Point 3

Point 4

Point 5

Normal in + z

Y

Figure D.1: Normal Calculation for a Polygon.

If the vertices are supplied in clockwise direction the normal calculated

faces in the other direction. When rendering a polygon, the user can pick between

WIREFRAME and SHADED. Also, the user can pick the desired side of the

polygon for shading. These sides are OUTSIDE and INSIDE. The OUTSIDE

side is the side for which the normal was calculated assuming counter-clockwise

specification of vertices. The Polygon class forms the basic building block of all

shapes that are created using procedural modeling. The class declaration is

specified in the file Shape.h (see Section D.5.3).



548

D.3.4. Class Attributes

This class can be thought of as a C structure that holds related data. In thiscase the Attributes class specifies the shading and the rendering characteristics of

a geometric shape. The shading characteristic can be INSIDE or OUTSIDE. This

specifies the side of a shape that gets shaded. The rendering characteristic can be

WIREFRAME, FACETED, or SMOOTH.

D.3.5. Class Shape

This class specifies an abstract data type that acts as the base class of all

possible 3D shapes. Specific shape classes are derived from this class. The key

members of this class are the ’number of polygons’, an ’array of polygons’ of which

make up the shape, and the ’attributes’ of this shape, and the ’origin’ of this shape

which is an instantiation of a Point. The origin member can later be used to add

bounding-volume capability to the Shape class. There are two public members

for setting the attributes of the Shape class. There is virtual method called Draw()

which is used to render the shape in the environment.

Here it is seen that rendering is a part of the Shape class. This is done

because these libraries are not intended for distributed use. Anyway, these

libraries can be easily ported by redefining the Draw method to be a part of the

Environment. Also, in the whole Shape class hierarchy, it is only the Draw

method that uses GL specific commands.

In the following paragraphs the classes derived from Shape are described.

D.3.6. Class QuadMeshShape : public Shape

This class groups together all objects that are made of quadrilateral strips

of polygons. This class redefines the protected method ’renderSmoothShaded()’ in

a manner such that it works efficiently for quadrilateral strips.



549

D.3.7. Class TriMeshShape : public Shape

This class groups together all objects that are made of triangular meshes.This class redefines the protected method ’renderSmoothShaded()’ in a manner

such that it works efficiently for triangular meshes.

D.3.8. Class PolyShape : public Shape

This class groups together all objects that are made out of flat polygons

(for i.e. buildings). This class redefines the protected method

’renderSmoothShaded()’ to be the same as ’renderFaceted()’. To draw an object of

type PolyShape, we simply draw the polygons that make up the object.

D.3.9. Class Cylinder : public QuadMeshShape

This class defines the abstract data type Cylinder. The key attributes of

Cylinder are its length and radius.

D.3.10. Class CylinderX : public Cylinder

This defines a cylinder whose axis is along the x-axis.

CylinderX cylx(length, radius, no_of_facets = 10, origin = 0, arcstart =

0.0, arcstop = 360.0);

D.3.11. Class CylinderY : public Cylinder

This defines a cylinder whose axis is along the y-axis.

CylinderY cyly(length, radius, no_of_facets = 10, origin = 0, arcstart =

0.0, arcstop = 360.0);

D.3.12. Class CylinderZ : public Cylinder

This defines a cylinder whose axis is along the z-axis.

CylinderY cylz(length, radius, no_of_facets = 10, origin = 0, arcstart =

0.0, arcstop = 360.0);



550

D.3.13. Class TruncCone : public QuadMeshShape

This class defines the abstract data type for a truncated cone. The keyattributes of TruncCone are its length, lower radius, and upper radius.

D.3.14. Class TruncConeX : public TruncCone

This defines a truncated cone whose axis is along the x-axis.

TruncConeX tcx(length, radius1, radius2, no_of_facets = 10, origin = 0,

arcstart = 0.0, arcstop = 360.0);

D.3.15. Class TruncConeY : public TruncCone

This defines a truncated cone whose axis is along the y-axis.

TruncConeY tcy(length, radius1, radius2, no_of_facets = 10, origin = 0,


D.3.16. Class TruncConeZ : public TruncCone

This defines a truncated cone whose axis is along the z-axis.

TruncConeZ tcz(length, radius1, radius2, no_of_facets = 10, origin = 0,


D.3.17. Class Extrusion : public QuadMeshShape

This class defines all shapes that are made by extruding a set of points in a

given direction for a specified length. The points should be specified in counter-

clockwise direction if the user is looking down at the cross-section from the

direction in which the extrusion is to take place. For example, to extrude an I-

Beam, the points are specified as shown in Figure D.2. In this case it is assumed

that the extrusion direction will be out of the page towards the user. If the

extrusion has to take place into the page, then the points should be specified in

clockwise direction. However, in the event of the points not being specified in the



551

right order, the user can toggle between INSIDE and OUTSIDE shading for a

shape to get the shading right.

P1

P5P4

P3P2

P6P7

P8P9

P10P11

P12

Figure D.2: Coordinate Specification for an I-BEAM Extrusion.

The syntax for constructing an Extrusion object is as follows:

Extrusion ibeam(pt_array, no_points, extrusion_length, extrusion_direction =

0, scale_x = 1.0, sacle_y = 1.0, scale_z = 1.0, closed = 0);

In this example of an I-Beam extrusion, we have:

pt_array -> Array of Points. (Point*)

no_points -> Number of points in pt_array (int)

extrusion_length -> Length the cross-section has to be extruded

extrusion_direction -> Direction in which to extrude.

If the extrusion_direction is specified to be zero or

is not specified at all, then the cross-section is

extruded in a direction which is normal to the cross-

section.

scale_x, scale_y, scale-z- ->This specifies the scaling in each direction

that is applied to the extruded end. For

example, using scaling, a circular cross-section can be extruded into an ellipse.

closed -> This specifies whether the first and last



552

points of the cross-section are joined

together or not. The default for this in ’not

joined’. A value of ’1’ makes the cross-

section closed.

D.3.18. Class Sweep : public QuadMeshShape

This class defines all shapes that are formed by rotating a set of points

about any specified axis. The points should be specified in counter-clockwise

direction if the user is looking down at the cross-section from the direction

opposite to which the sweep is to take place. However, in the event of the points

not being specified in the right order, the user can toggle between INSIDE and

OUTSIDE shading for a shape to get the shading right.

The syntax for constructing a Sweep object is as follows:

Sweep ibeam(pt_array, no_points, no_facets = 10, axis = 0, double arcstart = 0.0,

double arcstop = 360.0, closed = 0);

In this example of an I-Beam sweep, we have:

pt_array -> Array of Points. (Point*)

no_points -> Number of points in pt_array (int)

no_facets -> Number of facets to divide the sweep into

axis -> Direction of axis about which to sweep

If the sweep axis is specified to be zero or is not

specified at all, then the cross-section is swept about

the y-axis.

arcstart Value of the angle at which to start the sweep

arcstop Value of the angle at which to stop the sweep

closed -> This specifies whether the first and last points of

the cross-section are same or not. If the points are



553

same, then a 1 should be specified. This

information helps in the smooth shading of the

sweep.

D.3.19. Class Cone : public TriMeshShape

This class defines the abstract data type for a cone. The key attributes of

Cone are its height and radius.

D.3.20. Class ConeX : public Cone

This defines a cone whose axis is along the x-axis.ConeX conex(height, radius, no_of_facets = 10, origin = 0, arcstart = 0.0,

arcstop = 360.0);

D.3.21. Class ConeY : public Cone

This defines a cone whose axis is along the y-axis.

ConeY coney(height, radius, no_of_facets = 10, origin = 0, arcstart = 0.0,

arcstop = 360.0);

D.3.22. Class ConeZ : public Cone

This defines a cone whose axis is along the z-axis.

ConeZ conez(height, radius, no_of_facets = 10, origin = 0, arcstart = 0.0,

arcstop = 360.0);

D.3.23. Class Disk : public TriMeshShape

This class defines the abstract data type for a planar disk. The key

attribute of a Disk is its radius.

D.3.24. Class DiskX : public Disk

This defines a disk who’s normal is along the x-axis.



554

DiskX diskz(radius, no_of_facets = 10, origin = 0, arcstart = 0.0, arcstop = 360.0);

D.3.25. Class DiskY : public Disk

This defines a disk who’s normal is along the y-axis.

DiskY diaky( radius, no_of_facets = 10, origin = 0, arcstart = 0.0, arcstop = 360.0);

D.3.26. Class DiskZ : public Disk

This defines a disk who’s normal is along the z-axis.

DiskZ diskz(radius, no_of_facets = 10, origin = 0, arcstart = 0.0, arcstop = 360.0);

D.3.27. Class Box : public PolyShape

This defines a 3D box about a specified origin.

Box box(length_x, height_y, depth_z, origin = 0);

D.4. Class Diagrams

The class diagrams for the software developed for this project are given

below. The notation proposed by Booch [1994] is used for these class diagrams.



555

MatrixInverse()Multiply()

TransformMatrixToEulerZYZ()ToFixedXYZ()Multiply()

Vector

Vector3DCross()Dot()Magnitude()

Tensor

PointTranslate()Rotate()Extrude()

AttributesSetShading()SetRendering()

PolygonRenderShaded()RenderWireFrame()Draw()

ShapeoriginSetShading()SetRendering()Draw()

QuadMeshShape

PolyShape

TriMeshShape

N

1

Boxlengthwidthheight

1

3

N

1

1

N1

1

Figure D.3: Class Diagram One.



556

TruncConeradius 1

raduius 2heignt

Cylinderlengthradius

QuadMeshShape

CylinderZ

Sweep

lengthcross-sectiuonaxis of rotation

CylinderYCylinderX

TruncConeZTruncConeYTruncConeX

Extrusiondirection of extrusionscaling of extrusionlength

Figure D.4: Class Diagram Two.



557

Disk

radius

Coneheight

radius

TriMeshShape

ConeZConeYConeX

DiskZDiskYDiskX

Figure D.5: Class Diagram Three.



558

LightColor

Ambient

InfiniteLight

Direction

PointLightLocation

SpotLightLocationDirection

Spread

Material

Transparency

ShininessDiffuseAmbientSpecular

EnvironmentCreateWindow()

SceneRotation()SceneTranslationSceneZooming()SetActiveWindow()

Windowx_size, y_sizebackground_color

N

11

8

Figure D.6: Class Diagram Four.



559

D.5. Header Files

D.5.1. Rmath.h - Matrix, TransformMatrix, Vector, and Tensor

#ifndef MathH#define MathH

// Matrix.h -- matrix of type double

#include <stdlib.h>#include <iostream.h>

#define PI 3.14159265358979323846#define TWOPI 6.28319#define TRUE 1#define FALSE 0#define RADTODEG 57.29578#define DEGTORAD 0.017453293#define TINY 1.0e-20#define NULL 0

class MatrixCol;class MatrixRow;

typedef double diagonal;

typedef double* DoubleP;

class Matrix {protected:

int nrow, ncol;DoubleP *_m;void m_alloc(int rows, int cols);

public:Matrix(int nr =1,int nc =1,double* =0); Matrix(const Matrix&);Matrix(const MatrixRow&); Matrix(const MatrixCol&);Matrix(int,double*);

Matrix(int,diagonal);~Matrix();double& at(int irow,int icol) const{return _m[irow][icol];}double& operator()(int irow,int icol)const;operator double() const;MatrixRow row(int) const;MatrixRow row(int,const MatrixRow&) const;MatrixCol col(int) const;MatrixCol col(int,const MatrixCol&) const;



560

int isSquare() const {return (nrow == ncol);}int sameSize(int a,int b) const { return (nrow==a&&ncol==b); }int nRow() const { return nrow; }int nCol() const { return ncol; }void operator=(const Matrix&);int operator==(const Matrix&) const;Matrix t() const; // transposevoid t(Matrix&) const;void operator*=(double);double Determinant(void) const;void LUDecomposition(Matrix& result, int* indx, double* d) const;void LUFowBackSubstitution(int* indx, double b[]) const;void Inverse(Matrix& inverse) const;Matrix Inverse() const;void switchRows(int,int);void switchCols(int,int);void combineRows(int i,double b,int j); // row(i) += b*row(j)void combineCols(int i,double b,int j); // col(i) += b*col(j)int isUpperTriangle() const;Matrix upperTriangle();Matrix coFactor(int,int) const;Matrix coFactor(int,int,Matrix&) const;Matrix operator~() const; // inverse matrix, if anyvirtual void printOn(ostream&) const;virtual void dumpOn(ostream&) const;static void sizeError(char* where,const Matrix&,int,int);

}; // End of Class declaration for Matrix //determinantextern double det(const Matrix&);extern double norm(const Matrix&);extern Matrix operator+(const Matrix&,const Matrix&);extern Matrix operator-(const Matrix&,const Matrix&);extern Matrix operator*(const Matrix&,const Matrix&);extern Matrix operator-(const Matrix&); // concatenate columnsextern Matrix operator&(const Matrix&,const Matrix&); // scalar multiplyextern Matrix operator*(double,const Matrix&);class MatrixCol {private:

Matrix* pm;int _col; // index of this column

public:MatrixCol(int,const Matrix&);MatrixCol(const MatrixCol&);int nRow() const { return pm->nRow(); }double& at(int i) const { return pm->at(i,_col); }double& operator()(int i) const{ return pm->operator()(i,_col); }



561

void operator=(const MatrixCol&);void operator+=(const MatrixCol&);virtual void printOn(ostream&) const;

}; // End of class declaraion of MatrixColclass MatrixRow {private:

Matrix* pm;int _row; // index of this row

public:MatrixRow(int,const Matrix&);MatrixRow(const MatrixRow&);int nCol() const { return pm->nCol(); }double& at(int i) const { return pm->at(_row,i); }double& operator()(int i) const { return pm->operator()(_row,i); }double operator^(const MatrixCol&) const; // dot productvoid operator=(const MatrixRow&);virtual void printOn(ostream&) const;

}; // End of class declaration of MatrixRowextern ostream& operator<<(ostream& strm,const Matrix& m);extern ostream& operator<<(ostream& strm,const MatrixRow& m);extern ostream& operator<<(ostream& strm,const MatrixCol& m);

// class declaraton for Vectorclass Vector {protected:

int size;double *element;void init(int, const double *);

public:Vector(int sz) { init(sz, 0); }Vector(int sz, const double* array) { init(sz,array); }Vector(const Vector& v) { init(v.size, v.element); }~Vector() { delete [] element;}int GetSize() const{ return size;}void SetValues(double*) const {}double* GetArray() const {return element;}double GetMagnitude() const;double& at(int index) const {

return element[index];}double& operator[] (int index) const;Vector& operator=(const Vector&);int operator==(const Vector&) const;Vector& operator*=(double);Vector& operator/=(double);Vector& operator+=(double);Vector& operator-=(double);Vector& operator+=(const Vector& v);



562

Vector& operator-=(const Vector& v);}; // End of class declaration of Vectorextern Vector operator-(const Vector& v);extern Vector operator+(const Vector&, const Vector&);extern Vector operator-(const Vector&, const Vector&);extern Vector operator*(const Matrix&, const Vector&);extern ostream& operator<<(ostream& strm,const Vector& v);extern Vector GetRow(int row, const Matrix& m);extern Vector GetCol(int col, const Matrix& m);extern void GetRow(Vector& result, int row, const Matrix& m);extern void GetCol(Vector& result, int row, const Matrix& m); // end of method declaration for class Vector /********************************************************************/ // Class declaration for TransformMatrix

class TransformMatrix : public Matrix{public:

TransformMatrix(void);TransformMatrix(double f);TransformMatrix(const TransformMatrix& T);TransformMatrix(const Matrix& T);~TransformMatrix();void ToPumaOAT(Vector& end_location) const;void ToEulerXYZ(Vector& end_location) const;void ToEulerZYZ(Vector& end_location) const;void ToRPY(Vector& end_location) const;void operator=(const TransformMatrix& T);void operator=(const Matrix& T);

// this method multiplies a transformation matrix with another matrix which is // of type TransformMatrix. The transformation matrix is supposed to have last // row as { 0 0 0 1}

TransformMatrix operator*(const TransformMatrix& m) const{TransformMatrix result;this->Multiply(m,result);return result;

} // this is a faster version of the operator*(..) shown abovevoid Multiply(const TransformMatrix& with, TransformMatrix& result) const;TransformMatrix& operator*=(const TransformMatrix& m){ this->Multiply(m,*this);

return *this;}

TransformMatrix operator-(const TransformMatrix& m) const{TransformMatrix result;this->Subtract(m,result);return result;

}void Subtract(const TransformMatrix& with, TransformMatrix& result) const;



563

TransformMatrix& operator-=(const TransformMatrix& m){this->Subtract(m,*this);return *this;

}}; // End of method declaration for class TransformMatrix /***********************************************************************/

// Start if method declaration for class Tensortypedef Matrix* Matrixp;class Tensor {

friend ostream&operator<<(ostream& strm,const Tensor& t);

protected:Matrixp *mpp;int nmatrix, nrow, ncol;Matrixp* init_Matrix_array(int, Matrix* = 0);Matrixp* init_Matrix_array(int count, Matrixp*);

public:Tensor(int nm = 1, Matrix* = 0); // creates a nm X Nrow X Ncol Tensor and intializes the elements by 0Tensor(int nm = 1, int Nrow = 1, int Ncol = 1) {

nmatrix = nm; nrow = Nrow; ncol = Ncol;mpp = init_Matrix_array(nmatrix);

}Tensor(const Tensor& t){

nmatrix = t.nmatrix; nrow = t.nrow;ncol = t.ncol; mpp = init_Matrix_array(nmatrix,t.mpp);

}~Tensor();int nMatrix() const { return nmatrix; }int nRow() const { return nrow;}int nCol() const { return ncol;}Tensor& operator=(const Tensor&);double& at(int i, int j, int k) const{ // return i,j,kth element

return ((*(mpp[i])).at(j,k));}double& operator()(int i, int j, int k) const; // return i,j,kth elementMatrix& at(int i) const{ // return ith matrix

return (*(mpp[i]));}Matrix& operator()(int i) const; // return ith matrix (plane i)

};// End of method declaration for Tensor classextern ostream& operator<<(ostream& strm,const Tensor& t);#endif /*RMathH*/



564

D.5.2. Draw.h - Point and Vector3D class

/********************************************************************* FILE: Draw.h ** AUTHOR: Chetan Kapoor ** DATE: 21/9/94 ** REVISIONS: ** PURPOSE: This file declares the Point and Vector3Dclass ** NOTES: *********************************************************************/ #ifndef DrawH#define DrawH#include "Rmath.h"class Vector3D;

class Point;class Point{private:

double x, y, z;public:Point(double x = 0.0, double y = 0.0, double z = 0.0); Point(int i);Point(double*);Point(const Point&);~Point();double GetX(void) const { return x; }double GetY(void) const { return y; }double GetZ(void) const { return z; }

double& X(void) { return x; }double& Y(void) { return y; }double& Z(void) { return z; }void X(double x_val) { x = x_val; }void Y(double y_val) { y = y_val; }void Z(double z_val) { z = z_val; }Point Translate(double x, double y, double z);Point Scale(double x, double y, double z);Point Extrude(const Vector3D& v, double length);Point Rotate(const Vector3D& axis, double theta);double Magnitude(void) const;Point& operator=( const Point& p); Point& operator=( double d);Point& operator+=( const Point& p);

Point& operator-=( const Point& p);Point& operator+=( double d);Point& operator-=( double d);Point& operator*=( double d);Point& operator/=( double d);int operator==(const Point& p);int operator!=(const Point& p);



565

};extern Point operator+(const Point& p1, const Point& p2);extern Point operator-(const Point& p1, const Point& p2);extern Point operator+(const Point& p1, const Point& p2);extern Point operator-(const Point& p);extern void Rotate(Point*, int, const Vector3D&, double, Point*);extern Point operator*(const Matrix& m, const Point& p);extern Point operator*(const Point& p, const Matrix& m);extern ostream& operator<<(ostream& strm,const Point& p);class Vector3D : public Vector{public:

Vector3D(void);Vector3D(double x, double y, double z);Vector3D(double *array);Vector3D(double a);Vector3D(const Vector& V);Vector3D(const Point& p);Vector3D(const Point& p1, const Point& p2);double&X() { return element[0]; }double&Y() { return element[1]; }double&Z() { return element[2]; }void X(double x_val) { element[0] = x_val; }void Y(double y_val) { element[1] = y_val; }void Z(double z_val) { element[2] = z_val; }double GetX(void) const{ return element[0]; }double GetY(void) const{ return element[1]; }double GetZ(void) const{ return element[2]; }Vector3D Unit(void) const;Vector3D operator-(void);operator Point() const;

};extern Vector3D operator/(const Vector3D& v, double a);extern Vector3D operator*(const Vector3D& v, double a);extern Vector3D operator*(double a, const Vector3D& v);extern Vector3D Cross(const Vector3D& v1, const Vector3D& v2);extern Vector3D Dot(const Vector3D& v1, const Vector3D& v2);inline Vector3D Normal(const Vector3D& v1, const Vector3D& v2){

Vector3D result = Cross(v1, v2);return result;

}inline Vector3D UnitNormal(const Vector3D& v1, const Vector3D& v2) {

Vector3D result = Cross(v1, v2);return (result.Unit());

}#endif // DrawH



566

D.5.3. Shape.h - Polygon and Derivations of the Shape class

/********************************************************************* FILE: Shape.h ** AUTHOR: Chetan Kapoor ** DATE: 21/9/94 ** REVISIONS: ** PURPOSE: This file declares the Shape class ** NOTES: *********************************************************************/ #ifndef ShapeH#define ShapeH#include "Rmath.h"#include "Draw.h"

class Polygon; // forward declaration

typedef Polygon* PolygonP;

enum SHADING { OUTSIDE, INSIDE, BOTHSIDE };enum RENDER { WIREFRAME, SMOOTH, FACETED};

class Attributes{protected:

SHADING current_shading;RENDER current_rendering;

public: Attributes(RENDER render = SMOOTH, SHADING shading = OUTSIDE);Attributes(const Attributes& attr);int SetShading(SHADING);int SetRendering(RENDER);SHADING GetShading(void);RENDER GetRendering(void);Attributes& operator=(const Attributes& attr);

};

class Polygon{protected:

int number_points;Attributes attr;Point *point_array;Vector3D normal;

public:Polygon(Point*, int);Polygon(const Polygon&);



567

~Polygon();Polygon& operator=(const Polygon&);int SetShading(SHADING shading) { return attr.SetShading(shading); }int SetRendering(RENDER render) { return attr.SetRendering(render); }

Vector3D& GetNormal(void) { return normal; }Point* GetVertices(void) { return point_array; }void RenderWireFrame(void);void RenderShaded(void);void Draw(void);

};

class Shape{protected:

int no_of_poly; // maintains the number of polygons a // shape is made of

Attributes attr; // maintains whether the image is wireframe, // shaded, etc.

Point origin; // maintains the origin of the particular objectPolygonP *pp; // array of pointers to polygonsvirtual void renderSmoothShaded(void) = 0;virtual void renderFaceted(void);virtual void renderWireFrame(void);

public:Shape() {}virtual ~Shape();virtual void Draw(void);int SetShading(SHADING shading){

return attr.SetShading(shading); }int SetRendering(RENDER render) {

return attr.SetRendering(render);}

};

// class QuadMeshShape

class QuadMeshShape : public Shape{

protected:virtual void renderSmoothShaded(void);

};

// class TriMeshShape

class TriMeshShape : public Shape



568

{protected:virtual void renderSmoothShaded(void);

};

// class PolyShape; Shapes made out of flat polygonsclass PolyShape : public Shape{

protected:virtual void renderSmoothShaded(void); // for a PolyShape smooth

// shading is similar to flat // shading

};

// class declaration for Cylinder

class Cylinder : public QuadMeshShape{protected:

double length, radius;Vector3D *edge_normal; // array for holding the normals at each edge of

// the polygon for smooth shadingvoid renderSmoothShaded();

public:Cylinder(double length, double radius, int facets = 10, Point* center = 0 );Cylinder(const Cylinder&);~Cylinder();Cylinder& operator=(const Cylinder& );

};

// Class declaration for TruncConeclass TruncCone : public QuadMeshShape{protected:

double length, radius1, radius2;

public:TruncCone(double length, double radius1, double radius2, int facets = 10,

Point* center = 0 );TruncCone(const TruncCone&);TruncCone& operator=(const TruncCone&);

};

// Class declaration for CylinderXclass CylinderX : public Cylinder{



569

public:CylinderX(double length, double radius, int facets = 10,Point* center = 0,

double arcstart = 0.0, double arcstop = 360.0);CylinderX(const CylinderX&);

};

class CylinderY : public Cylinder{public:

CylinderY(double length, double radius, int facets = 10, Point* center = 0,double arcstart = 0.0, double arcstop = 360.0);

};

class CylinderZ : public Cylinder{public:

CylinderZ(double length, double radius, int facets = 10, Point* center = 0,double arcstart = 0.0, double arcstop = 360.0);

};

class TruncConeX : public TruncCone{public:

TruncConeX(double length, double radius1, double radius2, int facets = 10,Point* center = 0, double arcstart = 0.0, double arcstop = 360.0);

TruncConeX(const TruncConeX&);};

class TruncConeY : public TruncCone{public:

TruncConeY(double length, double radius1, double radius2, int facets = 10,Point* center = 0,double arcstart = 0.0, double arcstop = 360.0);

TruncConeY(const TruncConeY&);};

class TruncConeZ : public TruncCone{public:

TruncConeZ(double length, double radius1, double radius2, int facets = 10,Point* center = 0, double arcstart = 0.0, double arcstop = 360.0);

TruncConeZ(const TruncConeZ&);};

class Cone : public TriMeshShape{protected:

double length, radius;



570

public:Cone(double length, double radius, int facets = 10,Point* center = 0 );Cone(const Cone& c);Cone& operator=(const Cone& c);

};

class ConeX : public Cone{public:

ConeX(double length, double radius1, int facets = 10, Point* center = 0,double arcstart = 0.0, double arcstop = 360.0);

ConeX(const ConeX &);};

class ConeY : public Cone{public:

ConeY(double length, double radius1, int facets = 10, Point* center = 0,double arcstart = 0.0, double arcstop = 360.0);

ConeY(const ConeY&);};

class ConeZ : public Cone{public:

ConeZ(double length, double radius1, int facets = 10, Point* center = 0,double arcstart = 0.0, double arcstop = 360.0);

ConeZ(const ConeZ&);};

class Disk : public TriMeshShape{protected:

double radius;void renderSmoothShaded(void);

public:Disk(double radius, int facets = 10,Point* center = 0 );Disk(const Disk& d);Disk& operator=(const Disk& d);

};

class DiskX : public Disk {public:

DiskX(double radius, int facets = 10, Point* center = 0,double arcstart = 0.0,double arcstop = 360.0);



571

DiskX(const DiskX &);};

class DiskY : public Disk {public:

DiskY(double radius, int facets = 10, Point* center = 0, double arcstart = 0.0,double arcstop = 360.0);

DiskY(const DiskY&);};

class DiskZ : public Disk {public:

DiskZ(double radius, int facets = 10, Point* center = 0, double arcstart = 0.0,double arcstop = 360.0);

DiskZ(const DiskZ&);};

class Box : public PolyShape{protected:

double length, height, width;public:

Box(double length, double height, double width, Point* center = 0);Box(const Box&);Box& operator=(const Box&);

};

class Extrusion : public QuadMeshShape{protected:

int closed; // if = 1 draw closed shapedouble extrusion_length;double sx, sy, sz; // scales for the extruded pointsPoint *vertex_array; // pointer to a array of pointsPoint *extruded_points; // pointer to the extruded pointsVector3D extrude_vector; // vector along which to extrudeVector3D calculateDefaultExtrusionVector(Point* pt_array, int no_points);void calculatePolygons(void);void renderSmoothShaded(void);

public:Extrusion(Point* pt_array, int no_points, double extrusion_length, Vector3D*

extrusion_direction = 0, double scale_x = 1.0, double sacle_y = 1.0,double scale_z = 1.0, int closed = 0);

Extrusion(const Extrusion&);~Extrusion();



572

Extrusion& operator=(const Extrusion& );void SetDirection(double length, Vector3D* extrusion_direction = 0);void SetScaling(double x, double y, double z);void Draw(void);void GetExtrudedPoints(Point* pt_array, int* no_points){

*no_points = no_of_poly;pt_array = extruded_points;

}

};

class Sweep : public QuadMeshShape{protected:

int no_of_points; // no of points in the curve to sweepint closed; // are the input points closed. i.e first and last

// point are samePoint *input_pts; // pointer to a array of pointsVector3D axis; // axis about which to rotate

void calculatePolygons(int facets, double start_ang = 0.0, double stop_angle =360.0);

void renderSmoothShaded(void);public:

Sweep(Point*, int, int facets = 10, Vector3D* axis = 0, double start = 0.0, doublestop = 360.0, int closed = 0);

Sweep(const Sweep&);~Sweep();Sweep& operator=(const Sweep& );

};

#endif // ShapeH



573

D.5.4. Environment.h - Material, Environment, and Light

/********************************************************************* FILE: Environment.h ** AUTHOR: Chetan Kapoor ** DATE: 21/9/94 ** REVISIONS: ** PURPOSE: This file declares the Environment class ** NOTES: *********************************************************************/

#ifndef EnvironmentH#define EnvironmentH#include "Rmath.h"

#include "Draw.h"

#define dashed 1#define dotted 2

#define WT 1#define RD 2#define BLU 3

class Material{protected:

static int material_no;

int index;float alpha; // transparency of the material 0 //- 1.0. Default 1.0

float ambient[3]; // r,g, b components 0 to 1.0float diffuse[3]; // RGB components 0 to 1.0float emission[3]; // RGB components ranging

// from 0 to 1.0float specular[3]; // RGB components ranging

// from 0 to 1.0float shininess; // value ranging from 0 to 128void define(void);int checkValues(float, float, float);

public:

Material(float, float, float);int SetAmbient(float, float, float);int SetDiffuse(float, float, float);int SetEmission(float, float, float);int SetSpecular(float, float, float);int SetTransparency(float);int SetShininess(float);



574

void Bind(void);};

class Light{protected:

static int light_no;int index;float ambient[3]; // r,g, b components 0 to 1.0float lcolor[3]; // RGB components 0 to 1.0float position[4]; // x,y,z, and w

void define(void);int checkValues(float, float, float); // default is white light

public:Light(float R = 1.0, float G = 1.0, float B = 1.0);int SetColor(float, float, float);int SetAmbient(float, float, float);void Bind(void);

};

class PointLight : public Light{

public:PointLight(const Point& location, float R = 1.0, float G = 1.0, float B = 1.0);void SetPosition(const Point& location);

};

class InfiniteLight : public Light{

public:InfiniteLight(const Vector3D& direction, float R = 1.0, float G = 1.0, float B = 1.0);void SetDirection(const Vector3D& direction);

};

class SpotLight : public PointLight{protected:

float spot_direction[3];float exp, spread;void define(void);

public:SpotLight(const Point& location, float exp = 0.0, float spread = 180.0);void Focus(const Vector3D& direction);void ChangeAttributes(float exp, float spread);

};



575

// class declaration of Environmentclass Window;typedef Window* WindowP;class Environment{protected:

static int win_no;WindowP window_array[10]; // max of 10 windowsWindowP active_window;void generateMaterialDefinitions(void);void destroyMaterialDefinitions(void);void initializeViewing(void);void initializeDevices(void);

public:Environment(void);~Environment(void);WindowP CreateWindow(char*name , long size_x = 0, long size_y = 0);WindowP CreateWindow(char* name, long x1, long y1, long x2, long y2);void SetActiveWindow(WindowP win);void SetActiveWindow(long window_id);void SceneRotation(int* device, int no_device, void (*func)(void) );void SceneTranslation(int* device, int no_device, void (*func)(void) );void SceneZooming(int* device, int no_device, void (*func)(void) );void DrawScene(void (*func)(void));

};

class Window{

protected:long window_id;char w_name[32];float background[3];float view_ptx, view_pty, view_ptz;float view_sightx, view_sighty, view_sightz;float scene_rotx, scene_roty, scene_rotz; // rotations of the scenefloat trans_x, trans_y, trans_z; // translations of the scenefloat zoom_factor; // zoom-factor for the scenevoid initialize(void);

public:Window(char* name, long size_x = 0, long size_y = 0);Window(char* name, long x1, long y1, long x2, long y2);long GetWindowID(void) const { return window_id; }void Move(long orgx, long orgy);



576

void MoveRelative(long distx, long disty);void ResizeAndReposition(long x1, long y1, long x2, long y2);void SetMinSize(long x, long y);void SetMaxSize(long x, long y);void SetAspectRatio(long x, long y);void SetBackground(float* color);void SetViewSight(float x, float y, float z){

view_sightx = x; view_sighty = y; view_sightz = z;}void SetViewPoint(float x, float y, float z){

view_ptx = x; view_pty = y; view_ptz = z;}void SetSceneRotation(float x, float y, float z){

scene_rotx = x; scene_roty = y; scene_rotz = z;}void SetSceneTranslation(float x, float y, float z){

trans_x = x; trans_y = y; trans_z = z;}void SetZoomFactor(float z){

zoom_factor = z;}float* GetBackground(void) {

return background;}void GetViewSight(float& x, float& y, float& z) const {

x = view_sightx; y = view_sighty; z = view_sightz;}void GetViewPoint(float& x, float& y, float& z) const {

x = view_ptx; y = view_pty; z = view_ptz;}void GetSceneRotation(float& x, float& y, float& z) const {

x = scene_rotx; y = scene_roty; z = scene_rotz;}

void GetSceneTranslation(float& x, float& y, float& z) const {x = trans_x; y = trans_y; z = trans_z;

}void GetZoomFactor(float& z) const {

z = zoom_factor;}

};

#endif // EnvironmentH



577

D.5.5. Defines.h: Material and Color Declarations

/********************************************************************* FILE: Defines.h ** AUTHOR: Chetan Kapoor ** DATE: 21/9/94 ** REVISIONS: ** PURPOSE: This file contains some global material and color defs. ** All ’.c’ files which plan to use these material and color ** definitions should include this file ** NOTES: *********************************************************************/ #ifndef DefineH#define DefineH

class Material;

extern float yellow[3], blue[3];extern float ltblue[3], black[3];extern float white[3], red[3];extern float ltred[3], green[3];extern float ltgreen[3], gray[3], background[3];

extern Material *brightred, *darkred, *lightred;extern Material *brightgreen, *darkgreen, *lightgreen;extern Material *dullyellow, *creme, *lightcreme;extern Material *brightblue, *darkblue, *medlightblue, *lightblue;

extern Material *gray1, *gray2, *brushedalum, *polishedalum;extern Material *gray3, *flatblack, *lightbrown, *darkbrown;extern Material *flatwhite, *specularwhite, *specularblack;

#endif // DefineH



578

References

Aalund, M.P., “Design and Development of a Multi-Channel Robotic Controller,”

Master’s Thesis, Department of Mechanical Engineering, Univ. of Texas at

Austin, TX (1991).

Aalund, M.P., Geisinger, J.W., Puls, R.C., and Tesar, D. “Development of a

Digital Intelligent Servo Controller for Modular Robots,” Proceedings of the

Third International Symposium on Measurement and Control in Robotics,

AMMA-Via Vela 17-Torino, Italy, Sept., 1993, pp. Bm. I-31 to Bm. I-36.

ABB Robotics Incorporated, Operating/Teach Manual for Cincinnati Milacron T 3

600/700/800 series, Version 5.0, Release 5.0.

Aken, L.V., and Brussel, H.V., “Robot Programming Languages: The Statement

of a Problem,” Robotica, Vol. 6, 1988, pp. 141-148.

Alander, J.T., Frisk, M., Tuominen, J., and Vuolteenaho, M., “An Outline of a

Modular and Multiarm Assembly Cell with Object-Oriented Control,”

Proceedings IEEE International Conference on Robotics and Automation,

1990, pp. 592-597.

Ambrose, C., “The Development of an Interactive Synthesis Tool for IntelligentControllers of Modular, Reconfigurable Robots,” Ph.D. Dissertation, Dept. of

Mechanical Engineering, University of Texas at Austin, Austin, TX

(December, 1992).

Anderson, J.N., and Smiarowski, A., “A Fast Computer Architecture for the

Control of Robots,” Computers in Electrical Engineering, Vol. 17, No. 3,

1991, pp. 217-235.

Anderson, R.J., “SMART: A Modular Architecture for Robots and

Teleoperation,” Proceedings of the IEEE Conference on Robotics and

Automation, May, 1993, Atlanta, Georgia.

Banachiewicz, M., “SEL: Robotic Sensor/Effector Programming Language,”

Proc. IEEE International Conference on Robotics and Automation, Vol. 3,

1986, pp. 1779-1784.



579

Baugh, J.W.Jr., and Rehak, D.R., "Data Abstraction in Engineering Software

Development," Journal of Computing in Civil Engineering, Vol. 6, No. 3,July 1992, pp. 282-301.

Benedict, C.E., and Tesar, D., “Model Formulation of Complex Mechanisms with

Multiple Inputs: Part1-Geometry,” ASME Journal of Mechanical Design,

Vol. 100, 1979, pp. 747-719.

Bihari, T.E., and Gopinath, P., "Object-Oriented Real-Time Systems: Concepts

and Examples," IEEE Computer , December, 1992, pp. 25-32.

Birmingham, W.P., and Gupta, A.P., “The MICON System for Computer

Design,” University Libraries, Carnegie Mellon University, Pittsburgh,

Pennsylvania, 1988.

Bison, P., and Gini, M., “An Object-Oriented Approach to Robot Programming,”

Computer Integrated Manufacturing Systems, Vol. 2, No. 1, February 1989,

pp. 29-34.

Bit3 Computer Corporation, Multibus I-VME Adapter Model 422, User’s Guide.

Blume, C., and Jakob, W., “Design of a Structured Robot Language,” Advanced

Software in Robotics, 1984, pp. 127-143.

Bolinger, D., and Bronson, T., Applying RCS and SCCS. O’Reilly and

Associates, Inc., 1995.Bonner, S., and Shin, K.G., "A Comparative Study of Robot Languages," IEEE

Computer , Vol. 15, No. 12, 1982, pp. 82-96.

Booch, G., Object Oriented Analysis and Design with Applications. Second

Edition, Redwood City, CA: The Benjamin/Cummings Publishing

Company, Inc., 1994.

Boyer, M., Daneshmend, L.K., Hayward, V., and Foisy, A., "An Object-Oriented

Paradigm for the Design and Implementation of Robot Planning and

Programming Systems," Proc. IEEE Int. Conf. on Robotics and Automation,

April 1991, pp. 204-209.

Brain, M., Win32 System Services: The Heart of Windows NT . PTR Prentice

Hall, Englewood Cliffs, New Jersey, 1994.



580

Browning, G.T., “The Physical Significance of Kinematic and Dynamic

Performance Criteria for Serial Redundant Manipulators,” Masters Thesis,Dept. of Mechanical Engineering, University of Texas at Austin, TX (1996).

Bullock, D.M., and Oppenheim, I.J., "Object-Oriented Programming in Robotics

Research for Excavation," Journal of Computing in Civil Engineering, Vol.

6, No. 3, July 1992, pp. 370-385.

Burchard, R.L., and Feddema, J.T., “Generic Robotic and Motion Control API

Based on GISC-Kit Technology and CORBA Communications,”


April 1996, pp. 712-717.

Butler, M., and Tesar, D., "A Generalized Modular Architecture for Robot

Structures," Manufacturing Review , Vol. 2, No. 2, June 1989, pp. 91-118.

Butner, S., Wang, Y., Mangaser, A., and Jordan, S., “Design and Simulation of

RIPS: An Advanced Robot Control System,” Proceedings IEEE

International Conference on Robotics and Automation, Vol. 1, 1988, pp.

470-474.

Champeaux, D., Lea, D., and Faure, P., “The Process of Object-Oriented Design,”

Conference on Object-Oriented Programming Systems, Languages,

Applications, 1992, pp. 45-62.Chen, C., Trivedi, M.M., and Bidlack, C.R., “Simulation and Graphical Interface

for Programming and Visualization of Sensor-Based Robot Operation,”


May 1992, pp. 1095-1101.

Cheng, H. H., “Extending C and FORTRAN for Design Automation,” ASME

Transactions, Journal of Mechanical Design, Vol. 117, No. 3, Sept. 1995,

pp. 390-395.

Cimetrix Incorporated, “CX3000 Open Architecture Controller,” Product

Description, 1996.

Cleary, K., and Tesar, D., “Incorporating Multiple Criteria in the Operation of

Redundant Manipulators,” Proceedings IEEE International Conference on

Robotics and Automation, Vol. 1, 1990, pp. 618-623.



581

Coad, P. and Yourdon, E., Object-Oriented Analysis. Prentice-Hall, Englewood

Cliffs, NJ, 1990.Coplien, J. O., Advanced C++: Programming Styles and Idioms. Addison-

Wesley Publishing Company, 1994, pp.520.

Cox, I.J., "C++ Language Support for Guaranteed Initialization, Safe Termination

and Error Recovery in Robotics," IEEE Council on Robotics and Automation,

1988, pp. 641-643.

Cox, I.J., and Gehani, N.H., "Concurrent C and Robotics, "Proc. IEEE Int. Conf.

on Robotics and Automation, 1987, pp. 1463-1468.

Cox, I.J., Kapilow, D.A., and Kropfl, W.J., “Real-Time Software for Robotics,”

AT&T Technical Journal, Vol. 67, No. 2, March-April 1988, pp. 61-72.

Craig, J.J., Introduction to Robotics Mechanics and Controls. 1986, Addision-

Wesley.

Cybernet Systems Corporation, Implementation of a Compact 6 Degree of

Freedom Force Reflecting Hand Controller with Cueing Modes.

Duffy, J., Analysis of Mechanisms and Robot Manipulators, Wiley, New-York,

1980.

Duhaut, D., Bidaud, P., and Fontaine, D., “Iada: A Language for Robot

Programming Based on Ada,” Robotics and Autonomous Systems, Vol. 9,1992, pp. 299-304.

Force Computers Incorporated, Force CPU-30 User’s Manual, Revision 2.

Fresonke, D.A., Hernandez, E., and Tesar, D., “Deflection Prediction for Serial

Manipulators,” Proceedings IEEE Conference on Robotics and Automation,

April 24-29, 1988, pp. 482-487.

Geppert, L., “Solid State,” IEEE Spectrum, January 1995, pp. 35-39.

Giddings, R.A., “Development and Demonstration of General, Real-Time Control

Software for Robotic Manipulators,” Master’s Thesis, Dept. of Mech. Eng.,

Univ. of Texas, Austin, TX (1992).

Grossman, D., “AML as a Plant Floor Language,” Robotics and Computer

Integrated Manufacturing, Vol. 2, No. 3/4, 1986, pp. 215-217.



582

Grupinski, S., “Design of a System of Modular Robotic Actuators,” Master’s

Thesis, Department of Mechanical Engineering, Univ. of Texas at Austin, TX(1996).

Gruver, W.A., Soroka, B.I., Craig, J.J., and Turner, T.L., "Evaluation of

Commercially Available Robot Programming Languages, Tech. Pap. Soc.

Manuf. Eng., 1983, pp. 58-68.

Harima, T., and West, H., “Natural Robot Programming System,” Proceedings

IEEE/RSJ International Conference on Intelligent Robots and Systems, 1992,

pp. 750-756.

Hayward, V., and Paul, R.P., “Robot Manipulator Control Under UNIX RCCL:

A Robot Control “C” Library,” The International Journal of Robotics

Research, Vol. 5, No. 4, 1986, pp. 94-111.

Henderson-Sellers, B., and Edwards, J.M., “The Object-Oriented Systems Life

Cycle,” Communications of the ACM , September 1990, Vol. 33, No. 9, pp.

142-159.

Hernandez, E., Sreedhar, R. and Tesar, D., “Computational Requirements for the

Design and Control of the Fifth Generation Robot,” Robotics Research

Group, The University of Texas at Austin, 1989.

Hicks, C., Fundamental Concepts in the Design of Experiments. Springer-Verlag,Berlin, 1967.

Hill, B. M., and Tesar, D. "Rapid Analysis Manipulator Program (RAMP) as a

Design Tool for Serial Revolute Robots", Proceedings of the 1996 IEEE

International Conference on Robotics and Automation.

Hooper, R.N., “Multicriteria Inverse Kinematics for General Serial Robots,”

Ph.D. Dissertation, Dept. of Mechanical Engineering, University of Texas at

Austin, TX (1994).

Hooper, R.N., “The Interactive Assembly and Computer Animation of

Reconfigurable Robotic Systems,” Master’s Thesis, Dept. of Mechanical

Engineering, Univ. of Texas, Austin, TX (1990).

Horowitz, E., Sahni, S., and Anderson-Freed, S., Fundamentals of Data

Structures in C . Computer Science Press, 1993.



583

Hudgens, J.C., “Static Robot Compliance and Metrology Procedures with

Application to a Light Machining Robot,” Ph.D. Dissertation, Dept. of Mechanical Engineering, Univ. of Texas, Austin, TX (1992).

Hutchinson, S.A., and Kak, A.C., “Fprolog: A language to integrate Logic and

Functional Programming for Automated Assembly,” Proceedings IEEE


904-909.

Iaconics, J.M., “Design and Prototype Development of Robot Actuator Modules,”

Masters Thesis, Dept. of Mechanical Engineering, University of Texas at

Austin, TX (1991).

Isherwood, D., “DOS and Real-Time,” Third International Conference on

Software Engineering for Real-Time Systems, 1991, pp. 156-163.

Izaguirre, A., Hashimoto, M., Paul, R.P., and Hayward, V., “A New

Computational Structure for Real-Time Dynamics,” The International

Journal of Robotics Research, Vol. 11, No. 4, August 1992, pp. 346-361.

Jordan, D., “Implementation Benefits of C++ Language Mechanisms,”

Communications of the ACM , September 1990, Vol. 33, No. 9, pp. 61-64.

Kapoor, C., “Off-line Programming of a Robot Manipulator Using Graphical

Simulation,” Master’s Thesis, The University of Alabama, Tuscaloosa, AL(1992).

Kapoor, C., “Source Code Development and Formatting Guidelines,” Internal

Document, Robotics Research Group, The University of Texas at Austin,

1995.

Karlen, J.P., Thompson, J.M., Vold, H.I., Farrel, J.D., and Eismann, P.H., “A

Dual-Arm Dexterous Manipulator System with Anthropomorphic

Kinematics,” Proceedings IEEE Conference on Robotics and Automation,

1990, pp. 368-373.

Khosla, P. and Kanade, T., “Real-Time Implementation and Evaluation of Model-

Based Controls on CMU DD ARM II,” Proc. IEEE Conf. on Robotics and

Automation, 1986, pp. 1546-1555.



584

Knopf, C.A., “A Roadmap For Modular Robot Metrology,” Master’s Thesis,

Department of Mechanical Engineering, Univ. of Texas at Austin, TX(1994).

Korson, T., and McGregor, J.D., “Understanding Object-Oriented: A Unifying

Paradigm,” Communications of the ACM , September 1990, Vol. 33, No. 9,

pp. 40-60.

LaLonde, W.R., Thomas, D.A., and Johnson, K., "Smalltalk as a Programming

Language for Robotics," Proc. IEEE Int. Conf. on Robotics and Automation,

1987, pp. 1456-1462 .

Landman, R.G., “Selecting a Real-Time Operating System,” Embedded Systems

Programming, Volume 9, Number 4, April 1996, pp. 79-95.

Leu, M.C., "Robotics Software Systems," Robotics and Computer-Integrated

Manufacturing, Vol. 2, No. 1, 1985, pp. 1-12.

Lewis, T., “Where is Computing Headed?” IEEE Computer , August 1994.

Lippman, S., C++ Primer. 2nd Edition, Addision Wesely.

Lozano-Peréz, "Robot Programming," Proceedings of the IEEE , Vol. 71, No. 7,

July 1983, pp. 821-841.

Marrs, M., “Design of an Advanced, High-Precision, Seven Degree-of-Freedom

Modular Robotic Manipulator,” Master’s Thesis, Dept. of MechanicalEngineering, Univ. of Texas, Austin, TX (1996).

Mellor, S., Hecht, A., Tryon, D., and Hywari, W. “Object-Oriented Analysis:

Theory and Practice,” Course Notes, in Object-Orieneted Programming

Systems, Languages, and Applications. San Diego, CA: OOPSLA’88,

September 1988, pp. 1-3.

Miller, D.J., and Lennox, R.C., "An Object-Oriented Environment for Robot

System Architectures," IEEE Control Systems, February 1991, pp. 14-23.

Mohri, S., Takeda, K., Hata, Matsuzaki, S.J.K., and Hyodo, Y., “Robot Language

From the Standpoint of FA System Development - An Outline of FA-

BASIC,” Robotics and Computer Integrated Manufacturing, Vol. 2, No. 3/4,

1985, pp. 279-292.



585

Nakamura, Y., Advanced Robotics: Redundancy and Optimization. Addison-

Wesley Publishing Company, 1991, pp. 336.Narasimhan, S., Siegel, D.M., and Hollerbach, J.M., “Condor: A Revised

Architecture for Controlling the Utah-MIT Hand,” Proceedings IEEE


446-449.

National Instruments, “Instrumentation Reference and Catalogue,” 1996.

Oram, A., and Talbott, S., Managing Projects with make. O’Reilly and

Associates, Inc., 1995.

Pahl, G. and Beitz, W., Engineering Design: A Systematic Approach. Springer-

Verlag, The Design Council, Berlin, 1988.

Park, W.T., “The SRI Robot Programming System (RPS),” Technical Paper

Society of Mechanical Engineers, pp. 22-41.

Perry, B. R., “The Development of Distance Functions and Their Higher-Order

Properties for Aritifical Potential Field-Based Obstacle Avoidance,” Master’s

Thesis, Department of Mechanical Engineering, Univ. of Texas at Austin, TX

(1995).

Peterson, J, “Criteria-Based Performance Evaluation of Manual Controllers,”

Master’s Thesis, Department of Mechanical Engineering, Univ. of Texas atAustin, TX (1996).

Pimentel, J.R., "An Object Oriented Environment for Intelligent Automation

Systems," Proc. IEEE Int. Conf. on Robotics and Automation, 1990, pp. 723-

728.

Potter, D., “Getting on the Right Bus,” Test and Measurement World, February,

1992, pp. 65-70.

Potter, David, “Getting on the Right Bus,” Test and Measurement World ,

February, 1992,

pp. 65-70.

Press, W.H., Flannery, B.P., Teukolsky, S.A., and Vetterling, W.T., Numerical

Recipes in C The Art of Scientific Computing. Cambridge University Press,

Cambridge, England, 1991.



586

Puls, R.C., “Internal Communications and Interfaces for Modular Robotics,”

Masters Thesis, Dept. of Mechanical Engineering, University of Texas atAustin, TX (May, 1994).

Rackers, K.J., “Development and Demonstration of a Coordinated Control

System for Dual-Arm Robots,” Master’s Thesis, Department of Mechanical

Engineering, Univ. of Texas at Austin, TX (1996).

Rembold, U., Blume, C., and Frommherz, B.J., “The Proposed Robot Software

Interfaces SRL and IRDATA,” Robotics and Computer Integrated

Manufacturing, Vol. 2, No. 3/4, 1985, pp. 219-225.

Robotics Research Group, “The Development and Demonstration of a Class of

Modular, Dexterous, Medium Capacity Manipulator Structures,” Proposal to

DARPA (1991).

RogueWave Software, C++ Booch Components, C++ Class Library for

Multithreading and Storage Management, Class Catalog, Version 2.3

RogueWave Software, Tools.h++, Foundation Class Library for C++

Programming, Introduction and Reference Manual, Version 6.

Rubin, M.D., “Development of Real-Time Operational Software for Fault-

Tolerance Testbed,” Master’s Thesis, Univ. of Texas, Austin, TX (1993).

Salkind, L., “The SAGE Operating System,” Proceedings IEEE InternationalConference on Robotics and Automation, Vol. 2, 1988, pp. 860-865.

Schmitz, D., Khosla, P., Hoffman, R., and Kanade, T., “CHIMERA: A Real-

Time Programming Environment,” Proceedings IEEE International

Conference on Robotics and Automation, Vol. 2, 1989, pp. 846-852.

Schneider, S.A., Chen, V.W., Pardo-Castellote, G., “Control Shell: A Real-Time

Software Framework,” AIAA Conference on Intelligent Robots in Field,

Factory, Service, and Space, March, 1994.

Shanblatt, M.A., and Leung, S.S., “Computer Architecture Design for Robotics,”


Vol. 1, 1988, pp. 453-456.

Shlaer, S., and Mellor, S.J., Object-Oriented Systems Analysis: Modeling the

World in Data. Yourdon Press Computing Series, 1988, pp. 144.



587

Silberschatz, and Gahin, Operating Systems Concepts. Fourth Edition, Addision

Wesley, 1994.Smith, M.G., "An Environment for More Easily Programming a Robot," Proc.

IEEE Int. Conf. on Robotics and Automation, May 1992 ,pp. 10-16.

Soroka, B. I., “Designing Languages for Robot Systems,” Technical Paper

Society of Mechanical Engineers, 1984.

Soroka, B.I., “What Can’t Robot Languages Do?,” Technical Paper Society of

Mechanical Engineers, pp. 1-8.

Sreevijayan, D., and Tesar, D., "On the Design of Fault-tolerant Robotic

Manipulator Systems," Proc. of the Third Int. Symposium on Measurement

and Control in Robotics, Turin, Italy, September, 1993.

Stankovic, J.A., “Misconceptions About Real-Time Computing,” Computer ,

October 1988, pp. 10-19.

Stewart, D.B., and Khosla, P.K., “Real-Time Scheduling of Dynamically

Reconfigurable Systems,” IEEE International Conference on Systems

Engineering, Aug 1991, pp. 139-142.

Stewart, D.B., Schmitz, D.E., and Khosla, P., “Implementing Real-Time Robotic

Systems Using CHIMERA II,” Proceedings IEEE International Conference

on Robotics and Automation, 1990, pp. 598-603.Stewart, D.B., Volpe, R.A., and Khosla, P.K., “Integration of Real-Time Software

Modules for Reconfigurable Sensor-Based Control Systems,” Proceedings

IEEE/RSJ International Conference on Intelligent Robots and Systems, July

1992, pp. 325-332.

Strang, G., Linear Algebra and its Applications, Third Edition, Harcourt Bruce

Jovanovich, 1988.

Sturzenbecker, M.C. "Building an Object-Oriented Environment for Distributed

Manufacturing Software," Proc. IEEE International conference on Robotics

and Automation, April 1991, pp. 1972-1978.

Taylor, R.H., Korein, J.U., Maier, G., and Durfee, L.F., “A General-Purpose

Control Architecture for Programmable Automation Research,” Robotics

Research: The Third International Symposium, 1986, pp. 165-173.



588

Tesar, D., “Intelligent Actuators for Space,” White Paper, Robotics Research

Group, The University of Texas at Austin, TX (1996).Tesar, D., “Integration of Intelligent Machines and Robotics for Automation in

Automotive Plants,” White Paper, Robotics Research Group, The University

of Texas at Austin, TX (1996)

Tesar, D., “Operational Software For Enhanced Reliability and Performance of

Advanced Manufacturing Systems,” Texas ATP Proposal, June 22, 1993.

Tesar, D., “Status of U.S. Manufacturing,” Robotics Research Group, The

University of Texas at Austin, TX (1994).

Tesar, D., “Thirty Year Forecast: The Concept of a Fifth Generation of Robotics-

-The Super Robot,” Manufacturing Review, Vol. 2, No. 1, March 1989, pp.

16-25.

Tesar, D., and Matthew, G.K., The Dynamic Synthesis, Analysis, and Design of

Modeled Cam Systems. Lexington Books, 1976.

Thomas, M., and Tesar, D., “Dynamic Modeling of Serial Manipulator Arms,”

ASME Journal of Dynamic Systems, Measurement and Control, Vol. 104,

No. 3, 1982, pp. 218-228.

Todd, M., and Green, D.G., “An Object-Oriented Approach to Robotic Motion,”

Proceedings of the IEEE Southeastcon, 1993, 8p.Tomiyama, K., Honda, F., Shinoda, H., and Tanaka, J., “A Robot Control System

Based on a UNIX Work-Station,” IEEE International Conference on Systems

Engineering, Aug 1991, pp. 125-128.

Unimation Robotics, 500 Series Equipment and Program Manual, 398P1,

February 1983.

Van Doren, “Criteria Development to Support Decision Making Software for

Modular, Reconfigurable Robotic Manipulators,” Master’s Thesis, Dept. of

Mechanical Engineering, Univ. of Texas, Austin, TX (1992).

Volz, R.A., Mudge, T.N., and Gal, D.A., "Using ADA as a Robot System

Programming Language," Tech. Pap. Soc. Manuf. Eng., 1983, pp. 42-57.

Vuskovic, M.I., Riedel, A.L., and Do, C.Q., “The Robot Shell,” International

Journal of Robotics and Automation, Vol. 3, No. 3, 1988, pp. 165-176.



589

Wander, J.P., “Development of Robot Deflection Compensation for Improved

Machining Accuracy,” Ph.D. Dissertation, Dept. of Mechanical Engineering,University of Texas at Austin, TX (1992).

Wander, J.P., and Tesar, D., “Pipelined Computation of Manipulator Modeling

Matrices,” IEEE Journal of Robotics and Automation, Vol. RA-3, No. 6,

December 1987.

White, Z., Rational Rose Essentials: Using the Booch Method.

Benjamin/Cummings.

Whitney, D.E., “Resolved Rate Motion Control of Manipulator and Human

Prostheses,” IEEE Transactions on Man-Machine Systems, Vol. MMS-10,

No. 2, pp. 47-53, 1969.

Whitney, D.E., “The Mathematics of Coordinated Control of Prostheses and

manipulators,” Journal of Dynamic Systems, Measurement, and Controls,

94(4), pp. 303-309, 1972.

WindRiver Systems, AT&T Language System Library Manual, Version 3.0.

WindRiver Systems, VxWorks Programmer’s Guide, Version 5.2.

WindRiver Systems, VxWorks Reference Manual, Version 5.2.

WindRiver Systems, Wind Foundation Classes Component Release Supplement ,

1.0 Beta.Yeh, R.T., Software Engineering Report, International Software Systems Inc.,

July 28, 1993.

Yi, B.J., “Analysis of Redundantly Actuated Mechanisms With Applications to

Design and Control of Advanced Robotic Systems,” Ph.D. Dissertation,

Dept. of Mechanical Engineering, Univ. of Texas, Austin, TX (1992).

Young, G.E. and Douglas, E.G., “Real-Time Software Development Concepts for

Engineering Applications,” Proceedings of the Winter Annual Meeting of the

ASME , Nov. 25-30, 1990, pp. 1-7.

Yourdon, E., and Constantine, L.L., Structured Design. Prentice Hall, 1979.

Yuta, S. and Kanayama, Y., “Computer Architecture for Intelligent Robots,”

Journal of Robotic Systems, Vol. 2, No. 3, 1985, pp. 237-251.



590

Zheng, Y. F., “Integration of Multiple Sensors into a Robotic System and its

Performance Evaluation,” IEEE Transactions on Robotics and Automation,Vol. 5, No. 5, October 1989.

Zung, M., “The Design and Fabrication of a Two Degree of Freedom Knuckle

Joint for a Fault Tolerant Test Bed,” Master’s Thesis, Dept. of Mechanical

Engineering, Univ. of Texas, Austin, TX (1994).

Chetan Kapoor Dissertation

Documents

Transcript of Chetan Kapoor Dissertation