Embed Size (px)
Citation preview
Real-Time Distributed Control System Using CORBA
Tong Bao
B. Eng., Shanghai Jiaotong University. 1995
.A THESIS S U B h l l T T E D IN PARTI.4L FULFILLMENT
O F THE REQUIREMENTS FOR THE DEGREE OF
MASTER O F APPLIED SCIENCE
in the Department
of
Engineering Science
@ Tong Bao 1999
SIMON FRASER UNIVERSITY
August 1999
AU rights reserved. This work may not be
reproduced in whole or in part, by photocopy
or other means, without the permission of the aut hor.
National Libiary Bibliothèque nationale du Canada
Acquisitions and Acquisitions et Bibliographie SeMces services bibliographiques 385 W~llingttm Street 395, rue Wellington OctawaON K 1 A W OttawaON K1AON4 CaMds CaMda
The audior has granted a non- exclusive licence allowing the National Library of Canada to reproduce, loan, distribute or sell copies of this thesis in microforrn, papa or electronic formats.
The author retains ownership of the copyright in this thesis. Neither the thesis aor substantial extracts fiom it may be printed or ouienvise reproduced without the author' s permission.
L'auteur a accordé une licence non exclusive permettant à la Bibliothèque nationale du Canada de reproduire, prêter, distribuer ou vendre des copies de cette thèse sous la forme de microfiche/^, de reproduction sur papier ou sur format électronique.
L'auteur conserve la propriété du droit d'auteur qui protège cette thèse. Ni la thèse ni des extraits substantiels de celle-ci ne doivent être imprimés ou autrement reproduits sans son autorisation.
bstract
.A low-level closed loop real-tinie control system for multi-joint robot system is de-
signed and developed in C on a host PC under QNX. The real-time system uses the
MFI03.A controller to interface the host PC and the servo amplifiers. The control
system provides the user the functions including home, move and speed, to control
each of the joints simultaneously. Thc system software consists of controller. hard-
ware/software ini tializat ion, and user interface modules. .A tratli t ional standalone
real-time systein is not reusable by progranis riinning on heterogeneoiis platforrns.
CORBA middleware is used to make the real-time control system available to different
applications and processes on heterogeneous platforrns inciuding QNX and Windows
NT. A server prograni of the real-time system on a PC running Q N X and a client
program on a PC running Windows YT have been developed to control multi-joint
robcts from the QNX platform and to enable the client program to make function
calls to the server prograrn across the network.
Acknowledgrnent s
I would like to thank Dr. Bill Gruver who hns been supervising rny stiidy and research
For two pleasant years. Dr. Gruver introduced robotics and distributed systeni to me
and continuously facilitated and supported this research. I am grateful to Dr. Luya Li
who guided me through the thesis project stage by stage. Dr. Li patiently answered
my questions and freely shared his experience and knowledge. I wish to thank Dr.
Kama1 Gupta, Dr. Steve Hardy, Dr. John Jones. and Dr. Shahram Payandeli for
giving their time and energy to review this thesis. I appreciate advice of Dr. Marko
Vuskovic and Chris Paolini on the use of CORBA and the Orbix implementation. I wish to t hank Barbara Calvert for t horoughly proofreading t his t hesis.
Finally, I want to thank rny Eainily. without whom this thesis woiild tiot have been
possible.
Dedicat ion
To Miim, Dad. and Hillary
Contents
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approval 11 ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A b s t r a c t . . i i i
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgrnents. iv
Dedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . List of Tables ix
List of Figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 . 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 . 3 Research Overview . . . . . . . . . . . . . . . . . . . . . . . . '1 - 1.4 Organization of This Thesis . . . . . . . . . . . . . . . . . . . -1
1.5 Summary - 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Y Overview of Distributed Computing . . . . . . . . . . . . . . . . . . . 6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Introduction 6 - 2 . UNIX Interprocess Communication . . . . . . . . . . . . . . . I
L. 1 Client /Server Mode1 -.a. . . . . . . . . . . . . . . . . . . I
1.2.2 Signals and Pipes . . . . . . . . . . . . . . . . . . . . 8
m.-. '1 3 3 Message Queue and Semaphore . . . . . . . . . . . . 8
W.&* . . . . . . . . . . . . . . . . . . . . . 3 '2 4 Shared Memory 10
Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Remote Procedure Calls (RPC) . . . . . . . . . . . . 15
2.32 Common Object Request Broker Architecture (CORBA) 15
2.3.3 Cornmon Object Management (COBI) . . . . . . . . 21
2.3.4 Cornparison of COM and CORBA . . . . . . . . . . 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Summary 2 1
Implementation of a Real-Time Control System . . . . . . . . . . . . 28
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 s
. . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 System Design 29
3.2.1 Specificat ion Document . . . . . . . . . . . . . . . . 29
3.2.2 QNX Operating System . . . . . . . . . . . . . . . . 30
3.2.3 Control System Structure . . . . . . . . . . . . . . . 32
3.2.4 Pulse Wdth Modulation . . . . . . . . . . . . . . . . 3 3
t3.2.5 Position measurement . . . . . . . . . . . . . . . . . :34
6 Control algorithm . . . . . . . . . . . . . . . . . . . 35
. . . . . . . . . . . . . . . . . . . . . Softwareimplementation 3s . . . . . . . . . . . . . . . . . . . . 3.3.1 Program Modules 38
3.3.2 Synchroriization of Tasks . . . . . . . . . . . . . . . . -10
3.3.3 Task Data Structure Design . . . . . . . . . . . . . . 41
3 .. 3.4 lnitialization Module . . . . . . . . . . . . . . . . . . 42
. . . . . . . . . . . . . . . . . . . 3.3.5 Controller Module 50
3.i3.6 interface Module . . . . . . . . . . . . . . . . . . . . 58
3.4 Siirnrnary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
. . . . . . . . . . . . . . . . . . . . . . . . . . . CORBA Integration 67
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Integration 6Y
4.2.1 ORB Structure . . . . . . . . . . . . . . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . 4 . 2 . CORBA Interface 70
. . . . . . . . . . . . . . . . . . 4.2.3 Client-side Program 76 -CI 4.2.4 Server-side implementat ion . . . . . . . . . . . . . . 1 1
. . . . . . . . . . . . . . . . . 42.5 Server Main Function 80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . Experiments 87
4.3.1 MeasiiringTime . . . . . . . . . . . . . . . . . . . . 87
4.5.2 Experimental Setup . . . . . . . . . . . . . . . . . . Y7
. . . . . . . . . . . . . . . . . . . . . 4.3.3 Timing Results 90
vii
. . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Analysis 91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Summary 100
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conclusion 102
Appendices
. . . . . . . . . . . . . . . . . . . . . A Hardware Device Configuration 104
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . B Encoder Interface LUS
. . . . . . . . . . . . . . . . . . . . C MFIOSA Hardware Initialization 110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliography 1 1 3
viii
List of Tables
. . . . . . . . . . . . . . . Controller time for n control loops (in ns)
. . . . . . . Approxirnate cont coller time for one control loop (in nis)
. . . . . . . Time to invoke a dummy function once from NT (in ms)
Time to invoke a dummy function for n times from NT (in ms) . . . . Approximate time to invoke a dummy function once from NT (in rns)
Time to invoke a dummy function once from QNX (in ms) . . . Times that 9.99915 occiirred in 15x14 trials . . . . . . . . . . . . . . Time to invoke a dummy function for n times from YT (in ms) . . . .
4.9 Approximate tirne to invoke a dummy function once from QNX (in ms) 97
. . . . . . . . . . . . . . 4.10 Time to clo LOO0 ernpty loops on NT (in ms) 97
. . . . . . . . . . . . . 4.11 Time to do 1000 empty loops on QNX (in ns) 98
A . 1 Encoder settings on iVIFI0J.A cartl: N.C.= no connection . . . . . . . 106
t1.2 Encoder settings on MFI03.A card . . . . . . . . . . . . . . . . . . . 106
C.1 Initializing the hIFI03A cards by using MFIOJAinitfunction . . . . . 110
List of Figures
. . . . . . . . . . . . . 2.1 Pipes between three shell command processes
. . . . . . . . . . . . . . . . . . . . . . 2.2 An example message structure
. . . . . . . . . . . . . . . . . . . . . . 2.3 Message queue data structure
. . . . . . . . . . . . . . . . . . 2.4 hti example message queue structure
. . . . . . . . . . . . . . . 1.5 A binary semaphore used by two processes
2.6 Copying file data from server to client using pipe . FIFO. or message
queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Copying file data from server to client using a shared rnemory
. . . . . . . . . . . . . . . . . . . 2.Y Mapping a file into the address space
. . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Middleware architecture
. . . . . . . . . . . . . . . . 2.10 Middleware is a n integrat ion technology
. . . . . . . . . . . . . . . . 2.11 OMG's Object Management Architeture
. . . . . . . . . . . . . 2.12Common Object Request Broker Architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13 Object adapter
. . . . . . . . . . . . . . . . . . . . . . . 2.14 Structure of binary standard
. . . . . . . . . . . . . . . . . . 2.15 Location and packaging transparency
. . . . . . . . . . . . . . . . . . . . 2.16 Remote Procedure Cal1 structure
. . . . . . . . . . . . . . . . . . . . . . 3.1 QNX rnicrokernel architecture
3.2 Simplified block diagram of a real-time control system: c ( t ) is the con-
trolled variable . u(t) is the manipulated variable. r(nT) is the set point . t is a continuous time. and nT are sample times where n is an integer
. . . . . . . . . . . . . . . . . . . . . . . . . and T is the sampling rate
. . . . . . . . . . . . . . . . . . . . 3.5 PWM signal with 25% duty cycle 3-L
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Quadrature pulse 35
. . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Position rneasurenient 36
. . . . . . . . . . . . . 3.6 PID control structure in the real-time system 37 . . . . . . . . . . . . . . . . . . . . . . . . 3.7 PID control code segment 58
. . . . . . . . . . . . . . . . . . . . . 3.8 Control system software module 39
. . . . . . . . . . . . . . . . . 3.9 Synchronisation of tasks and real world 40
. . . . . . . . . . . . . . . . . . . . . . . . i3.10 Data structure for encoder 41
.3.11 Data structure for control calculation . . . . . . . . . . . . . . . . . . -12
. . . . . . . . . . . . . . . . . . . 3.12 Data structure for synchronization 43
. . . . . . . . . . . . . . . . . . . . . . .3.13 Initiaiizat ion module structure 45
. . . . . . . . . . . . . . . . . . . 3.14 Initialization of kEFIO:3A hardware -16
. . . . . . . . . . . . . . . . . . . . . . . . . 3.15 Checking setpoint buffer -47
. . . . . . . . . . . 3.16 One dimensional motion profile with three phases 49
. . . . . . . . . . . . 3.17 One dimeiisional mot ion profile wit h two phases 50
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18 Interrupt handling 52
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.19 Interrupt handling 54
. . . . . . . . . . . . . . . . . . . . . . . . 3.20 Data structure for encocier 5.5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.21 Encoder reading 56
3-22 Encoder mapping from counts to degree . . . . . . . . . . . . . . . . 57 . . . . . . . . . . . . . . . . . . . . . . . . . . 3.23 Calculate position error 58
. . . . . . . . . . . . . . . . . . . . . . . . . . J.24 Data in shared memory 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.25 Home function 60
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.26 Adding offset 62
3.27 Map the target positions for move functions . . . . . . . . . . . . . . 63
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28 Control structure 64
4.1 ORB structure of the real-time remote system . . . . . . . . . . . . . 69
4.2 IDL specification to real-time remote system . . . . . . . . . . . . . . i l
. . . . . . . . . . . . . . . . . . . . . . . 4.3 Inheritance of IDL interfaces 73
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Controller.hh 74
")C . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Memory management r o
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Client program 76
. . . . . . . . . . . . . . . 4.7 Implement server using BOAImpl approach 7s
. . . . . . . . . . . . . . . . . . 4.8 Implement server using T I E approach 79
. . . . . . . . . . 4.9 Implement server main() using BOAImpl approach 81
. . . . . . . . . . . . . . . . . . 4.10 Implement server using 'HE approach à1
4.11 Run time structure for t he real-time remote system . . . . . . . . . . 82
. . . . . . . . . . . . . . . . . . . . . 4.12 UseIIOPintheserverprogram Y5
. . . . . . . . . . . . . . . . . . . . . 4.13 Use HOP in the server prograrn 86
. . . . . . . . . . . . . . . . . . 4.14 hieasure the cont roller overhead time 88
. . . . . . . . . . . . . . . 4.1.5 Invoke dumrny lunction from Windows XT 89
. . . . . . . . . . . . . . . . . . . . 4.16 Invoke dummy lunction QNX PC 90
4.17 Controller overheacl time. invocation overhead time from local QM
PC, and invocation overhead tirne from remote NT PC . . . . . . . . 99
. . . . . . . . . . . . . . . . . . . . . . . . A 1 Real-time system hardware 10-1
. . . . . . . . . . . . . . . . . . . h.2 Interval timer and stopwatch timer 107
. . . . . . . . . . . . . . . . . . . . . . . . . . B.1 Encoder read interface 109
. . . . . . . . . . . . . . . . . . . . C . 1 MFI03A digital [/O configuration 112
Chapter 1
Introduction
1.1 Introduction
T w o motivations inspired this research. The first motivation came from the need for
the design and implenientation of a real-time system to control a dextrous hand from
a PC, using àIFI03X hardware and operating under QYX. The second motivation
was to enable the real-time control systern to be usecl by processes and applications
located on heterogeneous platforms across high-speed local networks. The Common
Object Request Broker Architecture (CORBA) technology was used to achieve system
integration of a real-time control system server on the QNX platform. and a client
program on the Windows NT platform.
1.2 Objective
This t hesis project concerns the design. development. and implementation of a real-
tirne robotic control system, and system's integration of the real time system with
heterogeneous operat ing systems.
A MFIO3A controlier hardware has been chosen to interface a host PC and the
servo amplifiers. The major emphasis of this thesis project is to design and implement
the real- time control system using the MFIO3.A hardware.
The second part of the research for this project is a system integration across corn-
puter networks. The real-time controller using is hosted on a stand-alone PC under
QNX. Real-time control systems often have the following limitations that complicate
their use in a networked system:
r The controi system is a starid-aloiie systerii, riot a sharrd resource.
The control system is not portable to other platforms such as Windows NT.
O The control system cannot communicate with other processes in other programs.
r The control system cannot he operated from a network.
To alleviate these difficulties, CORBA midclleware technology is used to integrate
the real-time control system with other platforms across the network.
The functionality of the controller is demonstrated by tasks of motor control on
a host PC operating iinder QNX. The functionality of the rernote control is demon-
strated by tasks of motor control from a PC operating under Windows NT across an
Ethërnet.
1.3 Research Overview
This bl ASc thesis project involves the design. development. and implementation of
a low-level closed loop real-time robotic control system in C. The control system
must provide the user with the functions to control each of the joints simultaneoiisly
from a host PC. This thesis project also designs, develops. and implements a system
integration of the real time control system with heterogeneous platforrns across a local
area network. The control system shall provide users on other platforms with the
ability to use the real time control systern as if it were available on local machines.
The control system must provide its service to different platforms including QNX,
UNIX, and Windows NT. The project is divided into two primary stages of development. Stage I focuses
on the developrnent of a real-time control system. The second stage focuses on the
development of a system integration. The real time control system in the first stage
will be the test bed of the system integration in the second stage. Stage II will expand
the real-time control system to a distributed object system across a local area high
speed network.
Real-Time Control Systern
Motivation for this project cornes from a dexterous robotic hand that has been devel-
oped in the SFU Intelligent Robotics and Manufacturing Laboratory. The dextrous
hand has three fingers with three joints for each finger. Force/torque sensors are
mounted on the fingertips. Each joint uses a DC servo rnotor and a PCVM servo
amplifier. The controller is implemented on a PC under the Q N X operating system.
Three blFI03A controllers are used to interface the host PC and the amplifiers. Each
BlF103A has three encocler-input channels, three 16-bit DIA channels. 2-t bits of digi-
tal [/O. and an interval t imer on board. Send- receive-reply communication protocol in
QNX is used to access the MFI03A hardware. The software driver for the hardware
inclucles t hree Q N X executables. DATAserver, PATHplaniier, SETPTserver. and a
set of routines to access the executables. The real-tiine control system is decomposed
into the follow ing processes: User Interface. Ini t ializat ion . and C'ont roller.
System Integration
Two important concepts in distributed cornputing are Remote Procedure Cal1 (RPC) and Client/Server models. The RPC rnakes procediire calls to other processes appear
to be normal calls within the calling process, however t h e RPC calls are executed
in other processes. The ClientIServer is a system in which significant processing is
done on the client, which also submits operations to the server for execution. In
the architectures of both RPC and Client/Server, the client communicates with the
server direct ly. A different met hod t hat has evolved is called middleware. Middleware
provides a functional layer between the client and server. This additional layer allows
clients to interact with a generic abstraction of a server, rather than with a specific
host and/or process. This abstraction allows applications to be developed to a stan-
dardizecl Application Prograrnming Interface ( API) without knowledge of the location
or implenientation of external functionality. In t his project, CORBA middleware is
used to develop and implement control. CORBA is a standard maintained by the Ob-
ject Management Group (OMG) for the distribution of objects across heterogeneous
networks. The development of the rernote system can be broken down into two parts,
the server program and the client program. Both programs are based on distributed
system and ob ject-oriented designs.
1.4 Organization of This Thesis
Ctiapter 2 presents an overview of existing distributed systern technologies. Top-
ics covered are the Unix !nterprocess Communication (IPC) and middleware. The
UNIX IPC includes signals, pipes. message queues. semaphores. and shared memory.
The middleware incl ides hlicrosoft Common O hject Management Mode1 (C'Oh1 ) and
Cornmon Object Request Broker Architecture [CORBA) from the Object Managrnent
Group (OMC). ..\ cornparison of COM and CORBA is also included.
Chapter 3 presents the first research focus of this thesis - a real-time control
system based on the Q N X operating system and MFIO3.A hardware for nine joints
robot control. Chapter 3 gives the detailed description of the design and development
of the Real-time Control System. The topics covered include control algorithrn and
structure, da ta structure design, and software module clevelopment . Chapter 4 presents the second research focus of this thesis - CORBA BIiddleware
integration of a real-time control system. Chapter 4 presents the Object Request
Broker (ORB) structure of the system integration and gives a detailed description
of design and development of the CORBA interface, the server-side implemeotation,
and the client-side application.
Chapter 5 concludes this thesis and presents ideas for future research.
1.5 Summary
In this chapter, WC describe the objective. the research overview and the o~ganization
of this thesis. This t hesis project has two contributions: a real-time controt system
that uses MFI03X hardware and is hosted on a QNX platform for miilti-joint robot
applications. and a methodology to integrate the real- the control system wit h ot her
applications on heterogeneous platforms by using CO RB A.
Chapter 2
Overview of Distributed
Comput ing
2.1 Introduction
The rise of Internet technology over the last two decades has decentralized computing
power to end users. This shift has dispersecl hardware resources throughout the
Internet. One of the most important features of the Internet is its heterogeneity.
For example, a local area network ( L A N ) can be macle up of mainframes. Sun or
SGI workstations running Solaris or Irix, PC systems running 4IicrosoR Windows
or hpple bfacintosh. Thus. the challenge is to develop a software infrastructure to
use these hardware resources. In this chapter. we will introduce the concepts and
implementations of the UNIX Interprocess Communication and Middleware systems.
These systems have evolved over the years and enable distribution of the cornputing
network.
Distributed applications have traditionally been developed by using relatively low-
level mechanisms such as the UNIX Interprocess Communication, the TCPJIP pro-
tocol, and the socket transport layer programming interface. These low-level mecha-
oisms provide applications with reliable, untyped, point-to-point services. They focus
on the performance rather than on the ease of programming, portability, flexibility,
or extensi biii ty.
The procedural remote procedure cal1 (procedural RPC) tools (such as the Sun
RPC and the OSF DCE) and the distributed object-oriented cornputing tools (DOC),
such as the CORB.4 and the COEUI, are called rniddleware (51. One major objective of
distributed computing is to allow developers to generate distributed applications using
techniques similar to t hose used for local applications, such as met hod calls on objects.
However, complicated components need to be developed to support niethod calls
on distributed objects transparent ly. The components include name service. object
request brokers (ORBs), interface definition langiiage compilers. and object location
and starticp iacilities that were developed in the niiddleware. The DOC provides many
of the same enhancernents to procedural RPC tools that object-oriented languages
provide to conventional procedural programming languages.
2.2 UNIX Interprocess Communication
The initial tool of distributecl computing was the C W X Interproccss Communication
( I P C ) . Generally, U N IX provides the following Application Progrnrn Inte riaces ( A P 1)
[46] :
a Signals. Pipes and FIFOs.
a System V Release 3.0 IPCs-message queues. sema phores, and s hared memory.
r Berkeley BSD sockets.
System V Release 4.0 Transport Layer Interface(TL1).
2.2.1 Client /Semer Mode1
The client/server model is the most popular model used for distributed computing
[Xi]. Programs (operations) are called clients (servers) according to their roles in the
communication protocol. The role of a client or a server is not fixed. When a program
opens a communication channel and waits for a request to execute some operation,
the program is called a server. The program rvhich initiates the communication and
sends the request is called a client.
2.2.2 Signals and Pipes
The oldest inter-process communicat ion met hods used by U NIX systems are signals.
A signal is used to indicate asynchronous events to one or more processes. A signal
can be generated by a keyboard interrupt or an error condition. For exarnple, if 1
type k i l l -1 on my SC1 workstation console, it shows the following signais:
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL RUS SEGV SYS PIPE ALRM TERM USRl
USR2 CHLD PUR WINCH tlRG POLL STOP TSTP CONT TTIN TTOU VTALRM PROF XCPU
XFSZ
The k i l l program terminates processes by sending theni signals. Signals are essen-
tially Rags that processes will check when they are awaiting their time slice. For
exarnple, the KILL signal is the surest sign to terminatc a process. Signaks are asyn-
chronous events that occur at random timcs to the process. So the process cannot
test a variable (such as errno) to see if a signal has occurred.
Pipes are uni-direct ional interprocess chanriels t hat conriec t the standard out put
€rom one process into the standard input of another process. A pipe is created by the
pipe function as follows:
# i n c h d e cunistd . h>
i n t p ipe ( int f d [2] )
where the fd[-] is a file descriptor. The p i p e function returns two file descriptors,
td[0] which is open for reading, and M[l] which is open for writing. If the command
p s Isort I lp is typed, the output of ps will be piped to the input of sort and the
output of s o r t will be piped to the input of l p . Figure 2.1 shows the structure.
2.2.3 Message Queue and Semaphore
In the pipes type communication. the byte stream flows between processes. In t h e
stream I/O model, no record boundaries exit. When the applications want to impose
some structure on the data being transferred, messages are used instead of only byte
streams. An exarnple of the message structure is shown in Figure 2.2. where each
message has three parts: rnesg-len, mesg-type,and mesg-data.
Figure 2.1 : Pipes between t hree shell command processes
A message queue is a linked list of messages that is stored in the kernel and
identifed by a message queue identifier 116]. The striict iire of a basic message queue
can be stiown as in Figure 2.4. A new queue is opened or createcl by the function
msget. New messages are added to the end of a queue by msgsnt. Messages are
retrieved from the queue by msgrcv. Using different algorithms to manipulate a
linked list. we can letch messages from a queiic in a way other than a first-in, first-out
order. The data structure of a sample message queue is shown in Figure 2.4.
A sernaphore is a primitive used to synchronize varioiis processes [46]. X simple
binary sernaphore used by two processes is shown in Figure 2.5. A semaphore is es-
sentially a counter t hat provides access to a shared data ob ject for multiple processes.
Three basic operations are used to operate on a semaphore. The first operation is to
create a semaphore and initialize it with a non-negative value. The seconcl operation
is to tuait for a semaphore. The operation checks the semaphore value. If it is less
than or equal to 0, the process waits (blocks) and decrements the semaphore value
once it is greater than O. The third operation is to post to a sernaphore. The operation
incrernents the value of the sernaphore. If any processes are blocked and waiting for
the semaphore's value to be greater than 0. one of them can be initiated now. h
semaphore can be initialized to any non-negative value N which usually represents
the number of resources available. This is called a counting semaphore.
struct mesg{ long mesg-len; long rnesg-type ; char mesg-data [maxdata] ;
-
in t mesg-send (st ruct mymesg *) ; int mesg-receive (struct mymesg *) ;
Figure 2.2: .-ln example message structure
niesgdata mesglen
2.2.4 Shared Memory
mesg-type
Shared Memory is the fastest form of IPC. It allows two or more processes to share a
region of rnemory. The data in the shared memory is available to al1 the processes. The
processes rnust often synchronize the use of the shared memory by using semaphores.
Consider a file copying program between a client and a server. Figure 2.6 shows the
usual procedures in using a pipe, F F O , or message queue. The server reads data
from the input file. The data are read by the kernel into its memory and then copied
from the kernel to the server process. The server then writes the data in a message
form of a pipe, FIFO, or message queue. Al1 these forms of IPC normally require the
data to be copied [rom the server process to the kernel. The client program reads the
data from the IPC channel, which requires the data to be copied from the kernel to
the client process. Finally, the client program writes the data into the output file.
We can see that it normaiiy requires four copying steps to use a pipe, FIFO, or
message queue in this case. Copying involves the data transmission between the kernel
s t r u c t mg-queue{ s t u c t mesg *mg-first; /* p t r t o f i r s t message on queue */ s t u c t mesg *mg- l a s t ; /* p t r t o l a s t message on queue */ i n t msg-qnum ; /* number of message on queue */ int msg-maxbytes ; /* m a x i m u m bytes on queue */ pid- t msg-lspid; /* pid of last rnsgsndo */ pid-t msg-lrpid; /* p i d of last msgrcvo */
3
i n t msget (key-t key , i n t f lag) ; i n t msgsnt(int msqid, const vo id *p t r , s i z e - t nbytes , i n t f l a g ) ; int msgrcv(int msqid, void *ptr, size-t nbytes, long type, int flag);
Figure 2.5: Message queue data structure
and the process, which costs more system resoiirces than copying within the kernel or
the process.
Figure 2.7 shows the usual procedures for the same copying between a server and
a client when using a shared niemory. The server prograrn gets access to a shared
rnemory object by using a semaphore. The server reads the data from the input file
into the shared memory object. When the read is finished, the server notifies the
client by using a semaphore. Then the client writes the data from the shared memory
object to the output file. Using a shared memory reduces data copying times between
the kernel and the processes to twice.
The mmap lunction maps a file into the acldress space of a process.
#include<sps/mmaa.h>
void *mmap(void *addr, s ize- t l e n , i n t p r o t , int flags, i n t f d , o f f - t o f f s e t )
Figure 2.8 shows this mapping. addr is the starting address within the process tocvards
which the file descriptor fd should be pointed. len is the number of bytes to map into
NULL h e d next O next -
Figure 2.4: An example message qtieiie structure
mq-mrixmsg
mq-msgsize
Figure 2.5: A binary semaphore used by two processes
the address space of the process, starting at ofset bytes from the beginning of the
file. prot specifies the protection of the memory-rnapped region. The protection has
four modes, permission to read. permission to write. permission to execute, and no
permission t O access.
priority=30
length= 1
Middleware
The IPC methods, pipe, FIFO, message queue. and shared memory, are involved
in the operating system level progamming. To enable users to write communica-
tion applications across a network without doing kernel level programming, another
,
priority=30
length='l
CHI1 PTER 2. OVERVlECV OF DfSTRIB UTED COW"I/~TfNCT
f \
server d'
readO pmcess - - - - - - - - - - - - - kenel
input message queue file
Figure 2.6: Copying file data from server to client using pipe, FIFO. or message queue.
paradigm calied middleware was created [SI. Figure 2.9 shows the middleware archi-
tecture. The middlware is a functional layer between the client and the server. This
layer provides services to the client-server communication such as naming, location.
alias resoliition, authentication, time synchronization. and translation between data
formats. The rniddleware layer allows the clients to communicate with an abstract
interface of the server, rather tban with a specific process or host. The abstraction
allows applications to be implementcd to a standard :\PI without knowing the loca-
tion and implementation of the server. The well-tlefined abstraction hicles the details
of implementation from the client applications, although it makes it difficiilt for t he
client program to determine the performance of the irnplementation.
2.3.1 Remote Procedure Calls (RPC)
An early mode1 of middleware is Remote Procedure Calls ( R P C ) . It is not a new idea
for a program to cal1 some parts in another program in a local host . The concept of
Locai Procedure Cali was naturally expanded to that of Rernote /+ocedure Cal1 when
the network technology put more and more resources on the Internet.
The RPC structure, as shown in Figure 2.16, has five parts involved in a remote
d l : the client progam and the client-stub on the client side, the server program
and the semer-stub on the server side, and the RPCruntime on both client and server
process - - - kernel
Figure 2.7: Copying file data frotn server to client using a shared memory.
machines [6]. When the client wants to make a remote call, it rnakes a normal local call
to invoke a procedure in the client-stub. The client-sttib will package the arguments
and ask the RPCruntime on the client machine to transmit the packets. When the
RPCruntime in the server machine receives the packets, it ivill ask the server-stub to
unpack them and make a normal local call again. This will invoke the appropriate
procedures in the server program. 3Ieanwhile. the calling process ori the client machine
is in a waiting state. When the call on the server program finishes. it returns to the
server-stilb and the results are passed back to the suspencled calling process on the
client machine. There the packets are unpacked by the client-stub and returned to
the client.
From this description, we can see several important concepts that are adopted
in the CORBA technology. First, the RPC client process makes a call to the stub
that appears ta be a standard function. Homever, rather than being executed locally,
the arguments passed to the functions are packed and transmitted into a remote
enviromerit. Second, there is a RPCruntime that is located between the client-stub
and server-stub that does the packet level communication. Third, the client interface
and the server interface need to be bound together. The binding operation in the
package binds an importer of an interface to an exporter of an interface. There are
two parts in a name of an interface, type and instance. The type part specifies which
CHAPTER 2. O VERVIE W OF DISTRIB UTED C'OrCIPLJTIiW
address space of a process
high memory n return value
low memory
file descriptor fd
1 1 t I 1 I 1 I I I I I
offset
Figure 2.8: Mapping a file into the address space.
interface the caller expects the server to irnplement. The instance specifies which
particular implernention of an abstract interface is iieeded. For example. the type of
an interface niight be a n abstraction of -cent roller'. and the instance would be one of
many controllers that are implernented in diflerent ways, such as our controller with
MF103A hardware.
2.3.2 Common Ob ject Request Broker Architecture (CORBA)
Object Management Group(0MG)
The Object !).lanagernent Croup was founded in 1989, by eight companies: SCom
Corporation, American Airlines, Canon inc., Data General, Hewlett-Pachrd, Philips
Telecommunications N.V., Sun Microsystems and Unisys Corporation. This consor-
tium now has over 800 members. The goal of the OMG is to create a cornponent-based
software marketplace by introducing standardized object software and establishing
CHAPTER 2. OVERVlEW OF DISTRIB UTED COMPCUXVG
Figure 2.9: hliddleware architecture
industry guidelines and detailed object management specifications. These guidelines
and specifications allow applications to be developed in a heterogeneous computing
environment across al1 major hardware platforms and operating systerns. ObIG's
popular Internet protocol Internet Inter-OR B Protocol ( I IOP) is being used as the
infrastructure for technologies provided by major companies which include Xetscape.
Oracle, Sun and IBM. These specificat ions are used to develop dist ri bu ted corn pu ting
applications for major industries such as manulacturing, finance. telecommunication.
electronic commerce. real-time systems and health Care. The OMG has three ma-
jor bodies, the Platform Technology Committee, the Domain Technology Committee,
and the Architecture Board. The Oh1 G relys on existirig technologies which are pro-
vided by its member companies. It does not carry out developrnent work itself. The
O MG issues Requests for Proposais ( RFPs) to recpest speci ficat ions of components
to fit into an Object dlanagernent Architecture (OMX). The member cornpanies may
propose specificat ions wi t h t heir implementation. A review and vot ing process is t hen
conducted. Once a specification is accepted. other vendors that conform to it may
offer alternat ive impiement at ions.
The OMG developed an object model, the OMG Object Mode1 (OMG/OM), which
is the underlying specification for al1 OMG cornpliant technologies. The Cornmon 06-
ject Request Broker Architectcire (CORBA) is an implementation of the specification.
Figure 2.10: Micldleware is an integration technology
The CORBA paradigm adopted two existing met hodologies. clistri buted client- scrver
computing and object-oriented programming. Distributed computing is based on
UNIX message-passing system.
CORBA is an integration technology rather than a programming technology. tt is
designed to be the glue t hat binds different programming technologies toget her. This
is illustratecl in Figure 2.10.
The OMG Object Model(OMG/OM)
The OMG/OM is a design mode1 instead of an implementation syntax.
The basic concepts of OkiG/OM are:
O Objects
Objects are instances of types. Types represent a group of entities which have
similar characteristics. Types may have subtypelsupertype relat ionshi ps.
Operations
Operations are defined by a signature cvhich has the name, parameters, and re-
turn values. The OMGJOM doesn't address the concept of exception handling,
public, private, or protected operations.
Subtyping
The OMG/OII supports subtyping and inheritance.
The CORBA Object Model
The CORBA Object Model is based on the OiLIG/OM (281. The abstract concepts
in the OMGIOM model are developed according to ideas from the CORBA Object
Model. The mode1 focuses on the interaction between clients and servers.
The clients make requests t hat consist of the target object . the operations. parame-
ters, and possibly context objects. The context objects usually contain environmental
information. An operation has a name. a result type. and parameters. .A parameter
declaration consists of a name. type and mode. The mode has two values. in and out
which specify the data flow directions between a server and a client. Exceptions can
be added in the operations. A n interface that provides a set of operations available
to clients is defined using an Interjace Definit ion Langaage ([DL). The model also
defines the types which fa11 into three categories: basic value. constructed value. and
ob ject reference.
Object Management Architecture (OMA)
Based on CORBA/OM, the OkIG defines the Object .\lanagernent ..lrchiiecture (OMX).
The OMA consists of four major parts l%] as shown in Figure 2.11.
0 Object Request Broker (ORB) The ORB is the core part of the ObIA, which provides the communication
infrastructure for the objects.
Application Objects
Appliation objects are the application identit ies.
0 Cornmon Facilities
Common Facilities are high-level services oriented towards end-usr applications.
application object
common facilites
J
object request broker (ORB) A
1 11 f v \
abject services
Figure 2. I l : ObIC's Object Management Architet cire
a Ob ject Services
Object Services are domain-independent interfaces, scich as the Naniing Service
which allows clients to find objects based on nanies.
Common Object Request Broker Architecture (CORBA)
The CORBA specification defines an architecture of interfaces and services that must
be provided by the ORB. The modules in this architecture are shown in Figure 2.12.
The ORB core provides the underlying communication rnechanism. On the client
side, the architecture provides three interfaces: the Dynnmic Invocation Interface
( D I I ) , the IDL Stub. and the ORB Interface [-Y]. The ORB interface provides the
operations that can be accessed by the clients or the object implementations. The
IDL stub is generated by the [DL laiiguage and linked to the client programs. It
provides the mapping between the client and the object implementation so that any
function call will be like a local call. The I DL Stub can only provide the interface t hat
is known in the compile-time. The Dynamic Invocation allows for the specification of
requests at run-time.
On the server side, the architecture provides four interfaces: the ORB Interface,
CHAPTER 2. OVERVIEW OF DISTRIBUTED COlclPLITING
object implementation n JJ1 interface 7 skeleton 1 1
ORB core
Figure 2.1'1: Cornmon Object Request Broker Architecture
interface A
object adapter
interface B
Figure 2.13: Object adapter
CHAPTER 2. OVERVIECV OF DISTRIBUTED COMP UTIVG 21
the IDL Skeleton, the Dynamic Skeleton lnterjace ( D S I ) , and the Object .Adapter (-81.
The ORB interface is shared by both the client and the server. The IDL skeleton is
the server-side counterpart of the [DL stub. The DSI is the server-side counterpart
of' the DII. As the DI1 allows clients to invoke requests without having access to
static stubs, the DSI allows servers to be written without having skeletons compiled
statically into the program. 'The Object Adapter serves as the glue between the object
implementation and the ORB, as shawn in Figure 2.13. .An object adapter adapts the
interface of anot her object to the interface expected by a caller. It allows the caller
to invoke requests on an object without the knowleclge of its triie interface. The lack
of an object adapter rneans that the object iniplementation has to be connected to
the ORB direct ly to receive requests. By staridarclizing many object iipcall interfaces
in the ORB, unnecessary size a.nd complexity will be added to the ORB.
2.3.3 Common Object Management (COM)
One notable absent vendor in the OhIG is Microsoft. Microsoft decided to create
its own Object Reqiiest Broker System called Conimon Object .\lanagernent (Cohl) .
The technologies built based on COM are Object Linking and Embedding (OLE) and
ActiveS. As part of the Windows family of operating systerns. CObI has been usecl
for many years in the development of software components. COkI was extended to
Distributed COM (DCOBI). In this section. ive present an overview of the key concepts
of COM and DCOM.
Interface
A COM interface defines the behavior of a component as a set of methods and prop-
erties. Each COM object can support one or multiple interfaces (called IL'nknown)
simultaneously. The interfaces are descri bed by using Mici-osofl [nt erface Definit ion
Language ( M I D L ) , which is an object-oriented extension of the DCE RPC IDL. The
MIDL compiler generates proxy and stub code in C or C++ from an interface defini-
tion. The proxy code provides a client-side application programming interface (API). Stub objects decode incoming client requests and locate the appropriate object on the
pointer to function 2 .-
component object r 3
function 2
VTBL pointer
private object data
1 data 1
- vitual table
Figure 2.14: Structure of binary standard
serser. Each interface is assigned a unicersally unique identifier (LWID) to prevent
name collisions. The identifier, called an interface identifier ( [ID) allows the clients
to determine if an interface is supported by an object [ -T l .
Binary Standard
COLI defines a binary cal1 standard which dictates t h e layout of the cal1 stack for al1
met hod invocations. COM essentially adopted the structure of Cf+ virtual tables
as the binary representation of an interface. The binary standard defines an interface
pointer as a pointer that points to a pointer t.o a function table. Figure 2.14 shows
the structure of a virtual table ['15. 50).
Classes
A COM class is an implementation of one or multiple COM interfaces. It provides
the real functions in a supported programming language for each interface method.
Each COM class has a unique identifier called a CLSID. The CLSID allows the clients
to find out the objects. One or more COM classes are packaged into a server. An
in-process COM server is a server which is loaded into the client address space as
a dynamic link library (DLL). An out-process COM server is a server which is a
separate executable running on the same machine as a client or a remote machine.
Client applications communicate wi t h CObI objects t hrough interface pointers. In the
case of an in-process COM server, calls go directly into an object that is created in
the client process. In the case of an out-process COXI servrr, calls go to an in-proccss
proxy object that invokes the requests by using a remote procedure call.
Location and Packaging Transparency
Components are deployed as DLLs or executables. COM client applications need not
be concerned with how a server is packaged or located. CObI requires providers of
CObI classes to register information about the type of server and the location of the
DLL or erecutable in a local registry. The client applications ilse COXI to create
objects based on a desired CLSID. The COM library locates the implementation of a
requested class. and establishes a connection between the client and the server. COM
use:; Lightweight Remote Procedure Cal1 (LRPC) for marshalling the local objects,
and Olject Remote Procedure C d (ORPC) for marshalling the remote objects (-71.
Figure 2. L -5 shows the location and packaging t ranspareiicy.
2.3.4 Cornparison of COM and CORBA
There are grt3at similarities betwveen CObI and CORBA. Both Cohl and CORBA
provide a framework based on the client/server mode1 for distributed objects. They
operate in a location transparent manner which means that a client can call a server
without the knoivledge of the server location. [ t is a daunting task to compare these
two technologies. W e not iced some diKerences bet ween two technologies during the
course of our project.
Platform Support
COM only supports Windows NT and Windows 95 before 1998. The vendor Software
AG ported DCOM to Solaris and OS/930. However, the response from the industry
CHAPTER 2. OVERVlEW OF DiSTRIBUTED COklPUTlNC;
: client process I I n client
! local server process on local I I I remote server process on I
remote machine I I . . . . . . . . . . . . . . . . . . . . . . .
Figure 2.15: Location and packaging transparency
was that DCOM was not proven outside of the Windows iarnily. CORBA has the
advantage on the platform coverage. It supports a wide range of UNIX and NT
platforms. For instance, CORBA supports the QNX operating system on which
our real-time control system is located. CORBA is also designed to support many
programming languages wi t hout requiring t heir modifications. CO RB.4.s language
mapping aiiows the IDL to be translated into the target languages. including Java,
C/C++, Smalltalk. Cobol, and Ada. Microsoft's emphasis is on developing languages
and tools which arc customized to support COkI. The emphasis is not on making
COB1 easier to support existing languages and compilers.
Ob ject Mode1
CORBA objects are defined in terrns of interface types. An object supports its inter-
face type and al1 its base types by inheritance. CORBX clefines an object reference
to identify an instance of an object uniqiiely. There is a separate object type called
ckas~. Interfaces are defined by a single inheritance of other interfaces in SIicrosoft
IDL. The base interface of al1 C'OM interfaces is IUnknown. COhI classes and inter-
faces are ident ified by the Universally Chique Ident ifiers ( UUID ) w hich are aclopted
from DEC RPC interfaces. In Cohl, an object nieans an instance of a COB1 class.
The relationship between a COhI class and the set of interfaces it supports is arbitrary.
The clients access the objects through a reference to one of the object's interfaces.
In COhI, the Iife circle is controlled by reference counting. The reference count is
incremented when a copy of the pointer to an object is generated, and is decremented
when the copy is no longer used.
Inheritance
COM is essentially binary integration. [t adopts the C++ virtual tables as the binary
representation of an interface. Because an interface is presented as a pointer to a
single table, interfaces cannot be defined using multiple inheritance. Ot herwise, t here
will be multiple pointers per interface which is undesirable. CORBX IDL supports
multiple inheritance. A client accessing a CORBA object holds a single reference to
the object. DCOM defines multiple interfaces for a given object instead of a single
interface inheri ted from rnult i pie interfaces.
Error Handling
CORBA IDL has built-in support for C++ exceptions and user-defined exceptions.
COM does not have this facility in the IDL level. Instead. CO31 returns a 32-bit error
code called HRESULT [-7'1.
Figure 2-16: Remote Procedure Cal1 structure
Caller Machine Cdlee Machine - - - - - - - - - - - - - - - - - - - - - - - - - - * - - - - - - - - - - - - - - - - - - - - - - - - -
\ \ I I
I t I I
I 1
1 User 1 I I 1
I I Semer @
I
I
; I
dl + work rerum
I 1 I : I : I I
I
I I I l I I I
lwd retum locdcall
I 1 I I 1 A I
I User-stub 1 Server-siub
I 1 1 I
&
1 l
I I
pack unpack : argument argument
I
I pack I ; argument argument
t I 1 I
1 I I I
I RPCRuntime I I RPCRuntime a I I
1 1 I 1 I
: nceive * wait + imsmit I
I I l
I I I I I I
I ---------------..---'
Cd1 packet
Result packet
I I I
; receive transmit I
I I I
l I
I I
2.4 Summary
In this chapter. we have described UNIX Interprocess Communication (IPC) and Mid-
dleware. The UNIX IPC mechanisms that we covered include signals, pipes, message
queues, semaphores, and shared rnemory. Middleware is a general name for the dis-
tributed system services which have standard programming interfaces and protocols.
Middleware is in a layer above the operating system and networking software. and
below industry-specific applications. Essantiaiiy, UXIX IPC mechanisms make up the
wvorld of networking. IPC rnechanisms alone are enough to irnplement network appli-
cations. However, the bliddleware AP I makes the network application development
easier by isolating the designers frorn the underlying networking mechanisms. The
Common Object Mode1 (COM) and the Common Object Request Broker Architecture
(CORBA) are the two most popular 4Iiddleware moclels. COM and the CORBA have
a great similarity in t heir structures. However. t hey have diffcrences in many areas
such as platlorm stipporting, object niodel. inheritance. and error handling. Between
CORBA and t h e COàI. only CORBA supports QNX.
Chapter 3
Implementation of a Real-Time
Control System
3.1 Introduction
In this chapter we present t he detailed design and implementation of a real-time
control system. .A real-time systern is characterized by timing constraints. A typical
real-time system consists of the controlling subsysteni (the cornputer controller ) and
the controlled subsystem ( the physical environment ). The interaction between t hese
two subsystems can be described by three operations: sampling. processing, and
responding [Ml. Al1 three operations must be performed within certain times. QNX is used as the OS for the real-time system. The MFIOM controller hardware is
used to interface the host PC and the servo amplifiers. The real-time control system
performs the computation of control setpoints in the host PC. sends the commands
to the digital to analog conversion in the kIFI03A hardware, and reads the encoder
feedback from the controlled joints t hrough the MFI03A hardware. The real-t ime
system provides position control for multi-joint robots. The systern uses a PID control
algorithm to compute the setpoint based on the joint position feedback. The Pulse
Width Modulation (PWM) is used for driving the actuators. The quadrature pulse
signal generated by the encoders is used for the sampling operation. The control
system software can be broken down to three modules: initialization, control, and
CHAPTER 3. IMPLEMENT-WlOiV OF .A REAL- T l M E COiVTROL Sk'STEM 29
interface. The init ialization module ini tializes the MFIO;IA hardware devices and
software processes for the other two modules. The controller module performs the
t hree operations of the real- t irne system: sampling, processing, and responding. The
interface module allows the user to interact wi t h the real- t ime system.
3.2 System Design
3.2.1 Specification Document
Real-Time Control System
Version 1.0
Data 10 August 1998
Introduction
The system consists of nine joints of a three-finger robot hantl. The system provides
the position control for the nine joints.
Joint Interface
1. Input from joint
Position feedback: encoder signal. range 0-5 V.
2. Ourput to joint
Position cont rol: analog signal. range - 10- 10 V.
;3. Control
A PID controller is used. The set point is to be entered from the keyboard.
Operator Communication
1. Operator intput
Choice from iunctions of homing, moving, and spinning.
CiH.4PTER 3. Ii,IPLEMEWI"4TION OF .4 REAL-TIME CONTROL SYSTEM 30
Target positions for nine joints.
Target speed for nine joints.
2. Console output
Display of horning, moving, and spinning functions.
Ciirrent joint positions during moving process.
Finishing status of required functions.
3.2.2 QNX Operating System
Real-Time Operating System
h real-time system accepts some type of input from its environment. and generates
output for that environment in an immediate and prcdictable fashion. The time franie
in a real-t ime system is in the order of milliseconds. The t irne recpired for a system to
respond to an event is called lutency [l]. The lower the latency. the better the system
responds to events t hat require immediate responses. A real- time system needs not
only a low latency, but also a deterministic response. The designer needs to know how
long it ivill take to perforrn a certain operat ion so t hat t irne intervals can be accoiinted
for in the system design. A general purpose operating systern siich as Windows NT
is non-deterministic, and may exhibit periods of high latency.
A real-tirne system requires both deterministic resporise and minimal latency. A
real-time operating system (RTOS) [-LI, a special type of operating system designed
wit h real-tirne needs, provides the designers with tools to meet the latter objectives.
RTOS provide rnemory allocation and management. input/output (110) functiotis.
net working, and funct ion li braries. In addition, RTOS have to be mult i- t hreaded and
preemptive. RTOS schedulers have to be able to preempt any thread in the system in
order to give the system resource to the thread tliat needs the resource the most. To
find which thread needs the resource most. the OS must assign priorities to threads
PI
CNAPTER 3. IiMPLEMENTATION OF A R E M - T I M E CONTROL Sk'S'TEM :31
After an investigation of available real- t ime operat ing sys tems, QNX was choseri as the
OS for this thesis project. QNX is a real-time operating system that fits a real-time
POSIX environment. It provides multi- tasking, priority-driven preemptive sclieduling,
and fast context switching [Xi]. QNX provides facilities to handle interrupt and
context switching in low latency and deterministic manner. For a Pentium 133 MHz
PC. the context switch latency and the interrupt latency are 2.6 psec and 4.4 psec,
respectively. A detailed performance profile can be found in reference [36].
QiUX is based on a microkernel which is less than 8KB in size. The microkernel
is dedicated to two essential functions of message passing and process rcheduling [:15].
The microkernel consists of a small collection of programs which makes it feasible for
the operating system to provide other services. The kernel provides four basic services:
process nrunuger. Jilesysstern manager. decice manager, and netmork rr1anagc.r. The
microkernel architecture on the PC. used for this thesis. is shown in Figure 3.1.
ernu87: Roiuing-point Emulator Manager lso9660fsys: CDROM k v i c r Manager
kv.= smd D~~~~~ M~~~~~ Net: Nciwork Manager
Dev.par: Pyallel kvice Manager EthnM9 Netwcrk hrcrface
k v . p i y : Pseudotetmind kvicr Manager Fsys-floppy: Floppy Disk k v i a M q e r
k v : Device Manager Dcv.ansi: Console Drive
Figure 3.1: QNX rnicrokernel architecture
Another important reason to use QNX, rather than other real-time operating sys-
tems, is that QNX is the only real-time operating system that is currently supported
by CORBA. Windows NT is a popular OS supported by CORBA. However, Windows
NT is a general purpose operating system that is not suitable for developing real-time
systems. Windows NT has too few priorities for processes and threads. Windows
NT has no priority inheritance mechanism. Therefore, the latency in Wiridows NT system is not predictable. A detailed analysis can be found in reference [47].
Linux, like other general purpose operating systems, is also designed to optimize
average systerii prrfortiiatiçe aiid ho give every procrss a fair &are of systeiii resùurcei.
Linux has system calls for suspending a process, but it does not guarantee that the
process will be resumed in a predictable time interval. A user process can be pre-
empted at an unpredictable moment and forced to wait for its share of the CPU time.
The t inie-sharing scheduling algo rit hni used in the Li nux kernel gives every process
a Fair share of CPU time. Therefore. assigning higher priorities to critical tasks does
not solve this problem. Another problem is that. Liniix virtual memory management
will swap any pages to the disk at any tirne. The time to bring back the reqiiested
pages is not predictable. Research has been carried out to create a real-time Linux
[3].
3.2.3 Control System Structure
A real-time system reads inputs from physical devices w hich are cont rolled, and sends
control signals back to the devices at specific times as determinetl by device operational
considerations. The system should not be limiteci by the capabilities of the cornputer
system. Our target real-time system can be depicted as s h o w in Figure 3.2. The
real-time control system hosted on a PC running under Q N X miist read inputs from
the robot actuators. provide the computed control. and write the output back to the
robot hand. In the simplified model, the systern can be divided into three major
tasks: actuation output, encoder feedback, and control cornputation.
The encoder feedback reads the pulses generated from the DC servo motors from
encoder channels. The control computation calculates the next setpoints according
to the proportion, integral, and diKerential control law. The actuat ion output writes
the drive output into digital to analog conversion channels.
The robot target system operates in real time and there is a time constraint for
CHAPTER 3. I M P L E M E N T T O OF A RErlL-TlhfE CONTROL SYSTEM 3 3
Figure 3.2: Simpiified block diagram of a real-time control system: c( t ) is the con- trolled variable. u ( t ) is the rnanipulated variable. r (nT) is the set point. t is a con- tiriuous time, and nT are sample tinies where n is a n integer and T is the sampling rate.
the system process. From Figure 3.2, we can see that hoth encocler sanipling and
actuation output need to be synchronized. The sampling rate t o rend input and write
oiitpttt is determinecl by the time constraint of the robot systern. The shorter the
time constraint. the faster the sarnpling rate needs to be. The tiost computer systern
must be synchronized to real time and m u t be able to carry out al1 the tasks-encoder
feedback, control computation. and actuation output within the sarnpling interval [4].
The basic idea of controlling motors based on the hardware in this thesis is to
adjust the voltages from the pocver amplifiers to the motors. The critical calculation
for voltage control is to compute the actuation from the position feedback.
3.2.4 Pulse Widt h Modulation
Pulse width modulation (PWM) is used for motor actuation. A pulse signal is a
constant frequency, two-valued signal in which the voltage values represent "on9and
"off" states. The percentage of "on' time is the duty circle. .A 25% duty circle is
shown in Figure 3.3. The frequency of the pulse signal should be hi& enough so
that the motors cannot respond to the on-off changes. The motor's speed will be
proportional to the average power from the amplifiers. The average power can be
adjusted by the proportion of the duty circle in a pulse. The larger the duty circle,
t he faster the motor speed. In order to achieve bi-directional motion, a second pulse
signal is utilized. The first signal provides an on-off signal as in the unidirectional
case, and the second signal provides control for direction [II.
I 1 I I J timc O T IT 31 4T
Figure 3.3: PWM sigrial wit h 25% duty cycle
3.2.5 Position measurement
signal pulse train is generated by an incremental optical device attached to the
shaft of the DC servomotor. Two 90-degree out-of-phase pulse trains (quadrature) are
obtained from the encocler. A typical quadrature encoder signal is shown in Figure 3.4.
The quadrature signals make it feasible to measure the position. From Figure 3.4
the combination state of the two pulse trains is unique [Il. On and off signals are
represented by 1 and 0. The combination of the two pulse trains is denoted as AB.
By observing the values of AB, we can see that moving focvard will give the sequence
10 11 01 00 10 11 ..., while moving backward will give the sequence 10 00 01 I l 10 .... The position change can be obtained by checking t h c new value of AB against the old
value. h position counter will be incremented when a forward movement occurs, and
decremented when a backward movement occurs. The method to get the position by
quadrature is indicated in Figure 3.5.
off 1 I O" n - i -
on PhaseA
off
l I I I I I I I the
. I I 1 I
l - , 1 )
I I I I t I I , I
Figure 3.4: Quadrature pulse
3.2.6 Control algorithm
Feedback of the motor position is obtained from the encoders. .A PID controller is
usecl for the control algorithni. The relation btitween the input and output can be
represented in the Laplace-domain as follows:
which corresponds in the time dornain to.
where e(t )=r(t )-c(t) and c(t ) are the measured variables; r(t ) is the reference value
or set point; e(t) is the error; ri, is the proportional gain; Iir is the integral gain:
and IID is the derivative gain. Figure 3.6 indicates the PID control structure in our
real-time system [31].
By discretizing the PiD control law in Equation 3.2, we oobtain
CHAPTER 3. Ii1fPLEMENTATION OF A REAL-TIME CONTROL SYSTEibi 36
Measure pos i t ion: < I n t errupt :
Old,state=AB; Read encoder channels t o g e t nev AB; Suitcb: Case : Old,state=OO ;
If(AB=lO) increment p o s i t i o n ; If(AB=Ol) decrement p o s i t i o n ; Else Error;
Case : Old,state=O 1 ; If (AB-OO) increment pcsit i o n ; If(AB=11) decrement p o s i t i o n ; Else Error;
Case: Old,s tate=l l ; If(AB=Ol) increment p o s i t i o n ; If(ABi10) decrement p o s i t i o n ; Else Error; Old,state=lO ; If(AB=11) increment p o s i t i o n ; If(AB=OO) decrement p o s i t i o n ; Else Error;
>
Figure 3.5: Position measurement
position feedbaçk from the cncoders
Figure 3.6: PID control structure in the real-time system
where s(n) is thc surn of the errors over [O, nT,] and Ts is the sampling interval of the
discret izat ion.
Lt is straightforward to write a computer algorit hm from Equation 3.3 and Eqiia-
tion 3.4. The code segment is shown in Figure 3.7: where I\', , Iir, and Ko are the
proport ional, integrat ional, and derivat ive gains, respect ively [-LI. Time is a critical factor for the real-time control system. In the real-tirne control
system, time is counted in microseconds. The nature of the real-time control reqiiires
only relative time. Therefore the interval timer is used. The interval time can be set
by the user. When the time starts, a task will run during the interval. When the
timer starts again, the task will also run again. Another timer is called a stop watch
timer. The stop watch timer is for tasks which happen a t an indeterminate tirne in
the future.
CHAPTER 3. 1ibIPLErC/IENT44TIO~V OF A REAL-TIME CONTROL SYSTEM 38
PID con t ro l loop: <
Figure f.7: PID control code segment
3.3 Software Implementation
3.3.1 Program Modules
From the above discussion the major tasks For the real-time systern are : 1) encoder
input; 2) control computation; 3) actciation output; and -1) synchronization of al1
tasks. The encocler input task will read and store the quadrature pulse trains which
are generated by a encoder. The control computation task will carry out the digital
calculation of the set point based on the quadrature pulse signals and t h e PID control
law. The actuation output tasks will write out the setpoint to amplifiers. The syn-
chronization task will keep the ot her t hree tasks to the outsicle devices in a real-time
manner.
From a viewpoint of computer implementation. ive require the following software
modules, as shown in Figure 3.8:
a Init ializat ion module
a Controller module
a Interface module
CHAPTER 3. I iWL E~~IELVTATION OF A REAL-TIME CONTROL SYSTEiCI 39
-
user module
controller ,:I>\
ini tirilization
mocfulc
hardware device
Figure 3.8: Control system software moclule
L'sers need to interact with the real-time system. b e r s mecl to read the infor-
mation frorn the real-time system when it is running, and send the corresponding
cornrnand back to the system. The interface modiile will cleal with the interaction.
The four tasks. encoder input, control computation, actuation output, and synchro-
nization occur i n the control module. A lot of data will be generated from the four
tasks. h better way to manage al1 these data, however, is to group them into a tight
data structure.
The software modules divide a relatively large. complex system into small parts.
However, one must consider interactions between these modules as shown in Fig-
ure 3.28. Improper identification of the interaction will result in wrong coordination
of these modules. In Figure i3.28, a shared rnemory and setpoint buffer are con-
structed, maintained, and destructed by a data server. The interrupt handler belongs
to the controller module which facilitates the synchronization.
Users employ the interface to send commands. The commands enter the data
Synchronization of tasks and outside world:
Inf inite control loop: synchronization; get data input ; control calculat ion; output actuat ion ;
3
Figure 3.9: Synchronization of tasks and real world
server. which manipulates the data. Users also retrieve informatiori from the data
server. The data server puts and retrieves data into the shareci mernory. and the dat,a
server gives the controller access to the sharecl memory. The user's path conimands
are sent to the path planner. The path planner t hen writes the setpoint out to a
setpoint buffer. Then the controller can read t he setpoint from the setpoint buffer.
3.3.2 Synchronization of Tasks
In a real-tirne system tasks are executed in a sequence which is not designed by the
programmer but by the environment. For example. the controller needs to read a
pulse signal when a pulse signal is generated. The designer cannot forcsee when an
outside event will occur, so tasks need to be syiichronized to the environment that the
system tries to control. A general form of a control program is shown in Figure 3.9.
In Our system, synchronization is carried out by the interrupt handler. The
LIF103A card generates interrupts both to the control of the timing for the con-
trol program running on the PC:, and notifies the PC of the occurrence of events. The
Row of the control program can be stopped temporarily to allow the interrupt handler
to run.
Encoder data structure :
Data: Buffer for pulses;
operat ion : Read encoder channel; Write encoder channel; Preload encoder channel;
3
Figure 3.10: Data structure for encoder
3.3.3 Task Data Structure Design
Before we implement the control algorit hm. ive need to build the objects in t h e cont rol
algorithm. Data structures are designed for the objects in the four tasks of the control
system.
Data Acquisition Task
The rnotor position pulse is generated by the encoders which are attached to the
motors. Thus, a data type and operations to store and handle the pulse signals are
needed. The basic data structure was designed as shown in Figure 3.10. Appendix B
shows the encoder interface.
Control Calculation and Actuation Output Tasks
The data structure for the control calculation task is shown in Figure 3.11. The
control calculation tasli reads the joint position input, and uses the PID control law
to compute the setpoints. The task can be decomposed into three operations, reading
incoming pulses, calculating PID output, and writing output. To design t-he three
operations, we need the data types for incoming pulses, setpoints, and PID data.
CHAPTER 3. IMPLEMENTATION OF A REAL-TIiLIE CONTROL SWTEiM 43
Control ca lcu lat ion and actuat ion output structure : i: Data:
Buffer f o r incoming pulses; Buffer for setpoint; Buffer f o r PID data; Buffer for DAC drive;
operat ion : Read incoming pulses ; PID calculat ion; Write DAC output;
3
Figure 3.11: Data structure for control calculation
The actuation output task adds the operation of writing the DAC output and the
associated data type of DAC drive.
Synchronizat ion
The data structure for the synchrotiization task is shown in Figure 3.12. The syn-
chronisation task is to control the timing of the control software running on the Q N X
PC, and to notify the PC of the event occurrence. Synchronization is achieved by
designing the controller loop as an iriterrupt routine. The interrupt handler uses a
QNX prory message to wake up a QNX process blocked on a recelva() command.
Therefore, the operation involves the manipulation of the prory message and interrupt
handling.
3.3.4 Init ialization Module
The initialkation process initiates the data server process. The function of the data
server process is to set up and provide access for other processes to the shared memory
Synchronisation structure: € Data:
Interrupt handler; Proxy t o vake up interrupt process;
operat ion : Set in t erval t imer ; Cet the interrupt handler; Attach the proxy ; Attach the interrupt handler ; Receive a proxy ; Detach the proxy ; Detach the interrupt handler;
1
Figure 3-12: Data structure for synchronization
. The shared mernory area is between the data server and controller process. The
data server allows other processes to access the data stored in the shared memory area
without interrupting the controller process. The initializat ion process starts up the
hardware server. set point, path planner, and controller processes. The initialization
process reads the elements in the shared memory area from an init ializat ion file. The
structure of the initialization module is shown in Figure 3. I R .
Data Server
The MFI03.A library provides a data server executable. To initiate the data server
executable, the following QNX process creation primitive is used:
i n t spavnl( i n t mode, const char* path, const char* arg0, ..., const char*
argn, NULL)
The spawnl creates a child process from the calling parent process. The environment
for the invoked program is inherited from the parent process. The program to create
the child data server executes concurrently with the necv child process by setting the
mode to PNOWAIT. The Spavnl function cvill return an error message i f it carinot
create the child process. The second check method is to use the Q X X library function
qnxnamelocate. The qnxnamelocate locates a process that has registered itself
under a given name. The data server PID is obtained from the dataServerIdGet
functioti which is from the data server executable.
MFI03A Interface
After the data server is started, the data types for the control system are constructed
and the memory space is created. The next step is to activate the iLIFI03A hard-
ware interface and to build up the communication between the control software and
the MF103.4 card. Figure 3.14 shows the structure of the initialization of MF1038
hardware. Appendix C shows the initializat ion in details.
start up data server process
start up
hardware process e initialize MFi03A
hardware
start up setpoint server process
stmup path planner server process
startup controller process
Figure 3.13: Ini tializat ion module structure
cleiu 9 encoder chmnels
and DAC channels
- - -
initialize PIT on board O
get PID period
load PID period to board O
configure SYNC signals on
board 0, 1 . 2 from the PET on board 0 1
1 cieiv intempts on board 1
enable SYNC interrupt o n
board o. 1.2
-- -
[son figure U& port A on board
Fi y r e 3.14: Initialization of MFIOJA hardware
. . . if ((bufsize = setptBuf sizeGet (0)) !=lOO) € bufSize = 100; if (setptBuf sizeset (O, buf Size) <O)
. . .> if ((j ointnum = numAxesGet (0) ) ! =9) < jointnum = 9; if (nubAxesSet (0, numAxes) <O
Figure 3.15: Checking set point buffer
Setpoint Server
The MFIOJA card provides a setpoint server. The setpoint allocates memory to
store a two dimensional array. If ive clenote the bufsize as the number of elernents
to allocate into a FIFO buffer, and j ointnum as the number of joints for the robot
system, the array size is [buf size] '[j ointnum]. The set point server also serves the
requests to manipulate and to get the information from the buffer. CVe define the
biiffer size as LOO, and the number of joints as 9 for the system in the initialization
file. In addition, these two numbers need to be checked in the software to make sure
rnemory space has been allocated successfully. The code segment of checking the
buffer is shown in Figure 3.15. The setpoint buffer should be set to zero before it is
used.
Path Planner
The setpoint buffer provides space in the memory to store the setpoints. After the
buffer is allocated, the path planner process can generate setpoints. The path planner
generates set points in bursts. The nurnber of set points in each of the bursts iç defined
in the value numSendPts. hfter sending a burst of setpoints. the path planner waits for
a period interval before sending the next burst of setpoints. The interval is generated
by the interval timer on board.
This real-time control system is a low-level control device. At a basic level. al1
coordinated motion trajectories can be considered to be one dimensional [3L]. For
instance. wit h movement in an n-dimensional space along an arbit rary corit iniioiis
pat h. the position is the distance traveled along the pat h, the velocity is t h e speed
along the path, and the acceleration is the rate at which the speed changes along
the path. They are al1 scalar quantities. For multi-joint coordinated motion we need
a mapping between the path in space and the control of the joints. Any number
of differcnt types of trajectories can bc generated based on a one dimensional path.
provided that the path is continuous and that the mapping betwen the path in space
and the joints is cornputable.
Consider a path p. The intial point is given by xi and the final point is given
by xj = x i + p. The speed at which the joint moves dong the path is s,. The
initial and final speeds are si and s j respectively. The magnitude of the maximum
acceleration permitted is given by Figure 3.16 which shows the speed versus time
for a one dimensional motion profile. The motion profile consists of three phases:
accelerat ion, criiise. and deceleration, wi t h durat ions of t a , t,, and t d respect ively.
The area under the motion profile is the pat h lengt h S. In some cases. the profile will
not reach its cruise speed and will stay within the specified path length. In this case,
the path planner will attempt to compute a motion profile with only acceleration and
deceleration phases to satisfy the path length constraint. This situation is shown in
Figure 3.17.
Usually the machine resolutions are needed for the path planner to decide if the
requested path is valid. The data required by the path planner are position, velocity,
CHAPTER 3. fMPLEMENTrlTION OF A REAL-TIME COIVTROL SYSTEM 49
and acceleration resolutions.
The position resolution is used by the path planner to determine when a nul1
trajectory is being requested. The path planner's position resolution should be set to
a distance that is less than the highest resolution that joints can travel betiveen two
consecut ive encoder edges [XI.
The velocity resolution is used to check the equality ol the cruise spted to eitiier
initial or final path speeds. If the two speeds are within the specified resolution,
t hen eit her the acceleration or decelerat ion phases can be eliminated. A s suggested
in reference ( 3 11, the velocity resolution is chosen to be 0.000 1.
The acceleration resolution is used to check when the specified maximum accel-
eration magnit iide for a pat h is close to zero. If a path is planned so t hat the speed
changes wi th a maximum acceleration magnitude of less than the acceleration resolu-
tion, then t h e system will give an error message.
When the path planner send the bursts of setpoints to the setpoint buffer. the
process canriot be interrupted by ottier conimands. Therefore. the path planner server
and the setpoint server should be set at the sarne level of privilege. After the above
initialization procedures, we can start the controller process.
Figure 3.16: One dimensional motion profile wit h t hree phases
CHAPTER 3. IMPL EMENTATIOX OF A REAL-TIME CONTROL S'L'STEM 50
Figure 3.17: One dimensional motion profile with two phases
3.3.5 Controller Module
The controller process is an infinite loop which is activated by the proKy from the
interrupt handler or QNX timer. When the cont roller process is act ivatetl. i t will read
the setpoint from the setpoint FIFO buffer. The controller process reacls the actual
position of the joint. The set points are adj iisted according to the actual positions of
the joints. Then the controller process computes the actuator drive levels by using
the control filter. The cont roller process saves data including the setpoint and actual
position into the shared mernory area so t hat t hey can be accessed by ot her processes.
The cont roller process converts the computed drive levels to 16- bit integer equivalent s
and writes them to DACs.
QNX Inter-process Communication
The controller process not only computes the PID control algorithm, but also syn-
chronizes the timing of computation and joint movements. In order to achieve syn-
chronisation, QNX Inter-process Communication (IPC) is used. The QXX Kernel
supports three kinds of interprocess communication: messages, proxies, and signals
[W. Messages are the fundamental fonn of IPC in QNX. A message is a packet of
bytes that is synchronously transmitted from one process to another. To cornmunicate
direct ly wit h one anot her, cooperating processes use the following C functions:
0 Sand() for sending messages,
O Receive () for receiving messages,
Reply() for replying to process that have sent messages.
These functions can be used locally or across the network. T h e process of sending a
message requires a reply from a receiving message.
.A proxy is a special form of message. .A proxy is a type of non-blocking message.
When a process is not allowed to continue executing. because it must wait for some
part of the message protocol to end. the process is said to be blocked. For example.
when a message is sent, the sending process becomes SE.VD-blocked iint il the receiving
process B issues a Fieceive() to receive the message. When a proxy is sent. the
sending process does not neecl to interact with the recipient. so it is not blocked. The
only function of a proxy is to send a fixed message to a specific process that owns
the proxy. By using a proxy. a process or an interrupt handler can send a message to
another process without blocking or having to wait for a reply.
Signals are a traditional form of IPC. They are used to support asynchronous
interprocess communicat ion.
Interrupt Handler
From the previous design, we can see that the key to communication between the
controller software and the hardware device is the synchronization. hmong al1 the
synchronization methods, CVe chose the interrupt handling method to impiement the
synchronization, because the QNX C li brary provides low-level funct ions t hat direct ly
support interrupt handling design. The code segment showing the interrupt handling
software structure is presented in Figure 3.19.
PIT on MFi03A interrupt -
Figure 3.lS: Iritcrriipt handling
CHAPTER 3. IMPLEMENTATION OF A REAL- T1ME CONTROL SYSTEM 53
The main program was designed as an infinite loop that waits for the interrupts
from the BIFI03A card in order to wake the controller process. The prozy is an
IPC signal with a canned mcssage. The pid-t qnx-proxy-attch(pidf p id , char*
data, i n t nbytes, i n t p r i o r i t y ) function generates a proxy that is attached to
the process pid. The proxy can take a message with a length of nbytes pointed to by
data. When any process sends to a proxy, it will cause the proxy to send its message
to its owner. The process which sends to the proxy will not block. and the data sent
to the proxy will be discarded. The proxy acts like a messenger which is always ready
to send its message. :\ user kicks it to send a message by sending étnyt hing to it. The
rnechanism of using interrupt handling is shown in Figure 3.18.
The i n t qnxhintmttach(unsigned intnum, pid-t (* handler) (void) , unsigned
ds) function attaches the interrupt function handler to the hardware interrupt intnum.
The controller process should be in the body of the interrupt fiinctiori handler (1. However, it woiild cause the interrupt handler too long. As a result. the controllcr
process is developed as a separate module characterised by a n infinite loop waitirig
for a proxy to activate it. The body of interrupt hancller sends the proxy mcssage to
the cont roller module.
Encoder Reading
The pulses showing the niotor position are generated by the optical encoders attached
to the motors, Three encoder channels on the hIFIO3A card can transmit the encoder
counts. The encoder data input is the first part of the control loop. Encoder reading
must be carefully implemented due to the cons t raint s of encoder registers.
One revolution of the motor in our test bed corresponds to 500 counts. The motor
ratio is 18'i:l. Therefore, the encoder gain is 5OO*l8ï=935OO. In order to provide
data for motor position and rnovernent direction. the encoder generates a quadrature
pulses signal. Considering the quadrature signals, the encoder line t hat the counters
will count for every resolution of motor is 9350OX7*2= 37.1000. However, the encoder
counts are stored as a =-bit 2's complement integer in a11 encoder registers (3-1. The
range of the encoder counters is only 24 bits, although 33-bit values can be achieved
# i n c h d e Cstdio . h> t include <sys/ irqinfo .h> t include ~sys /proxy .h> t include <sys/kernel.h>
pid-t proxy;
/* The hardware interrupt handler w i l l return a proxy */ pid-t f ar handler() { return (proxy) ;
> void c o n t r o l l e r h i t () (
i n t i d , i ; /* Cet a proxy f o r t h e interrupt handler t o kick */ if ((proxy = qnx-proxy-attach(0,0,0,0))=-1)<
printf ( " Unable t o attach proxy . ' ' ) ; return -1 ;
> /* Attach to the interrupt handler on the MFIOJA card */ if((hlntId=qnx,hint-attach(iruptNum, Bhandler, FP-SEG(&numMFIO3As)))==-1){
printf ( " Unable t o att ach interrupt handler . ' ' ) ; r e tu rn - 1 ;
1
void mainline()( f o r ( ; ; )€
/*liait f o r proxy */ Receieve (ctrlProxy ,O, 0) ;
Figure 3.19: Interrupt handling
Checking encoder reading range:
encoder-change = enc-oldenc; if (encoder-change < -Maxchange ; ) roll=roll+rollsize;
if (encoder-change > Maxchaage; ) roll=roll-rollsize;
get the remainder of roll; 3
Figure 3.20: Data structure for encoder
by a sign extending the count to 32 bit. In the program. the counts are stored by a
signed long integr. With this format, the range of the encoder counts is -8,388,608
to 8.388.608. This means that the counter can only count with resolution -22 to +22.
A bigger range needs to be obtained by software design. The design of this method
is shown in Figure 3.20.
To check the rollitig over or rolling iinder of the encoder count reading, two ar-
guments are needed: the rnaximum speed of the systern in terrns of encoder counts
per second, and the maximum time between latching the encoder and reading the
encoder. Thus, the maximum magnitude of the change which can occur in the count
between two consecutive encoder latches is obtained. When the encoder change is
bigger than the positive maximum change, the counter hns rolled over the range and
needs to be incremented. If the encoder change is less than the negative maximum
change. the counter has rolled under the range and needs to be decreniented. The
design of the encoder reading is illustrated in Figure 3.21.
When we allocate rnemory space for the encoder reading, we need to Jefine the fol-
lowing data, as in the above discussion: e n d C31, encl C33 , enc2 [31, cnt s-persev [9] , roll [9 ] , and rollsite Cg]. e n d [3] . encl [33, and e n d [3 ] store encoder data
from the t hree MFI03A cont rollers. Each cont roller feat ures t hree encoder channels.
Allocate t h e memory space t o encoder reading; Read the o l d encoder data from 9 channels; Control loop : 1 Read the 9 encoder channels; Check if t h e encoder counter r o l l over or r o l l under; Save the o l d counter for the next time t o check r o l l over and r o l l under ; Map encoder reading t o plus or minus half the number of counts per revolut ion;
>
Figure X2 1: Encoder reading
c n t s p e r z e v Cg] contains the counts per revolution For nine motors. These are de-
cided by their count per turn (CPT) and gear ratio. roi l [g] will record the count
roll over or roll under when it exceeds +22 turns or -22 turns. The r o î l s i z e Cg] is the
maximum counts that the encoder register can count without rolling over or rolling
under. To read the encoders, the function i n t encReadAll(int boardNum, long
i n t * e x ) is used. I t is important to keep track of the old encoder data because the
encoder data must be checked against the overflow. The encoder data are the counts
per revolution, which should be mapped to the position in degrees. Furthermore,
the actual position needs to be defined within -180 degrees and +LS0 degrees. This
can achieved in the algorithm as shown in Figure 3.22. The remainder is obtained
by dividing the overtiow-adjusted encoder reading against the counts per revolution.
Then the remainder is compared against the half value of the counts per revolution
to get the mapping value between plus and minus half counts per revolution.
declare remainder [9] ; remainder [il = (enc [il +roll [il ) Xcnt s-par-rev [il ; if (remainderco) enc [il = remainder [il + cnts-par-rev ci] ;
if (remainder [il cents-per-rev Ci] / 2 ; enc ci] = remainder Ci] ;
else enc Ci] = remainder [il - cnts-pet-rev [il ;
return enc Ci] ;
Figure 3.22: Encoder mapping lrom courits to tlegree
Actuation Calculation and Output
Once the encoder data are read, the actuation process will start. The ac tua l positions
of joints are obtained by converting the encoder data. In the backgroiind, the path
planner cornplites the path and sends the setpoints t o the setpoint buffer in bursts.
The reading of the setpoint buffer follows the reading of the encoders. The setpoint
data should also be mapped to the value of -180 degrees to +180 degrees. This
corresponds the actual position reading t hrough the use of the same method shown
in Figure 3.22.
The critical information for the control loop is the position error defined as the
difference between the setpoints and the actual positions. In theory, the joint reaches
the required position when the position error is zero. However, it is neit her feasible
nor necessary in practice to use this as the criterion. A major reason is that there is
always an error in the encoder reading. .A minimum error value is defined as the error
resolution. When the position error reaches the error resolution, the error should be
consiciered zero. From the discussion, we c m determine that the minimum error in
terms of degrees should be degrees per count in one joint revolution. Also, the values
CHAPTER 3. IMPLEMENT'TlON OF A REAL-TIM E CONTROL SYSTEM 58
. . *
declare posError Cg] ; declare posRes [9] ; posError Ci] = actualPos [il -setptPos [il ; if (posError [il <= -180.0) posError [il =posError CiD360.0 ;
if (posError Ci] H80.0 posError [il = posError [il -360;
if (posError [il terrRes [il ) 1 1 (posError [il >-errRes [il ) posError [il =O ;
Figure :1.23: Calculate position error
of +LSO degree and the -180 degree are in the same position. We want the position
value to be unique. The algorithm to implernent the position error calculation is
shown in Figure 3.23.
The next step is to cornpute the drive data using PID control law. The Coordinate
Mot ion Control C: library provides the function int PIDcalc(SHAREDJEMSTRUCT *)
to perform the calculat ion ( 3 11. Before calling the PIDcalc () function. the fiinction
int PIDinit (SHAREDMEMSTRUCT) has to be called, and the data in Figure 3.24 have
to be obtained. The output of the PID calculation are then written to DAC channels
by using the function int DACwrit eAll (int boardNum , short *data).
3.3.6 Interface Module
The User Interface Process defines functions for the joint rnotor motions of the dex-
trous hand, such as home, move, and speed. The functions sends path requests to the
path planner process and information requests to the data server process by using the
path planner and data server executables in the library. The path request cornmands
a particular motion of the joint. The information request retrieves information such
CHAPTER 3. IbIPLEkIENTATIOiV OF il REAL-TIhI E CONTROL S k'STEM 59
number of the j o i n t s ; p o s i t i o n error; sampling time in PID control law; p o s i t i o n constant i n P I D control lav; integral constant i n PID control law; d i f f e r e n t i a l constant i n PID control law; b ias value i n PID control l a v ; windup value i n PID control lav; saturat ion value i n PID control law.
Figure 3-24: Data in shared memory
as current machine position and status for display. The path planner process gener-
ates set points and pass them on to the set point buffer process. The set point buffer
process is a first-in-First-out (FIFO) buffer. Set points sent by the path planner are
stored to be read by the controller process in the order t hat tliey arrive.
Interface Design
Different methods can be used to develop a user interface. The interface [or the host
PC running QNX is designed by using UNIX curses functions [17].
Joint Home Function
The first function for t his real-time cont rol system is the function to home nine motors.
Basically, two functions need to be used in the interface. One is to send the home
commond, the other is t-O check the homing status. Both furictions need to get access
to the data server. The CMC library provides two routines which perform the services,
homeAxisSet () and homeAxisGet 0. The controller program needs to know if a home
cornmand is coming by checking the value of home. aris t hrough the data server. The
process can be illustrated in Figure 3.25.
I n t e r f a c e module: I:
a..
Send home 9 joints command t o d a t a s e m e r ; Loop :
check the home s t a t u s from the d a t a s e rve r ; \ \ . . *
3 3 Con t ro l l e r module: i
... Inf i n i t e loop :
Waiting f o r proxy t o wake me up; * * .
If homeing is i n process and preloaded is not done Preload t h e encoder;
... I f homing posError C e r rorRes; Homing is done; . * .
I f homing o f f s e t is not s e t ; s e t the o f f s e t ;
L . .
I f homing is needed; <
S t a r t homing ; S e t t h e path planner p r i v i l e g e high;
1
Figure 3.25: Home function
CHAPTER 3. IMPL EiC.IENTATTOI\r OF -4 REAL-TIME CONTROL SYSTEM 6 1
When a home function is started, it has to set the privilege level of the path planner
to zero so that the path planner will not accept pat h commands from other processes.
The homing motion is achieved by using the line() function in the CMC library.
The iine() generates linear setpoints for a n-dimensional linear movement from an
initial set of positions to a final set of positions. In our case, it is a nine-dimensional
linear motion for a set of position changes of 360 degrees.
When a home function is started, the encoder needs to be changed to hardware
preload. As illustrated in Figure B.1, the encoder's preload register is latched into the
encoder counter when the index pulse ( 2 phase). as shoivn in Figure 3.4. goes high.
After the preload is latched, the preload enable is autornatically disabled.
Sometimes there is an error in the initial encocler reacling. However. it is not
often the case. The initial state of setpoint. actual position. and position error should
satisfy the following relation.
To solve t his problern. an offset value is added to eliminate the error. The program
adding offset is shown in Figure 5.26.
Joint Move F'unction
Otie basic joint fiinction is to move the joints from initial positions to required posi-
tions. An interactive screen interface was developed by using screen functions in the
headfile: <curses.h> from the Watcom C/C++ compiler. When a user chooses the
move function, the interface will show the current positions of joints. The current
positions are obtained by using function posSave(int serverNum, HORD n J o i n t s , unsigned long*ctrlCnt , double pos [9] ) , where the c t rlCnt is the controller
tirner. The controller timer synchronizes the encoder reading with the real joint
movements. The controller increments a count each time it is activated by the proxy.
After the display of the current positions, the interface will get the target positions
for joints from the screen by asking the users to input the target positions. The inpiit
value is an ongular distance that needs to be mapped to a value of between -180
degrees to +180 degrees. The aigorithm for the mapping is shown in Figure 3.27.
Beginning of the control module: €
start homing f unct ion ; setptOf f set [il =setptPos [il -actualPos [il -posError [il ; . . * loop : €
setptPos Ci] =setptPos [il -setptOff set [il ;
Figure 3.26: Adding offset
The minimum angular distance between the initial and final positions is corn puteci to
adjust the final positions for a linea: path. Then a line command iine(0, 9, Qi , Qt , o. O , vcru i se , o . 0, amax, dt , 3) is used to send the command to the data
server, where Qi and Qt are initial and target positions. In order to determine i f the
move function has finished, we check the remaining setpoints in the setpoint buffer
by using the cornmand setptBufGetNumEntries(). When there is a single entry left
in the setpoint buffer, the path has been completed.
CHAPTER 3. IMPLEMENTATION OF A REAL-TIME CONTROL SYSTEibf 63
//Read the current posit ions from the data s e m e r , / / the current posit ions are stored i n Qi[9]; ... //Read the target posit ions from the screen input, / /the target posit ions are stored i n Qt[9] for(i=O; i<9; i++){
Q t Ci] = (Qt Ci] X36O) *36O ; if (Qt [il >=IBO. O) {Q [i>360 ; 3 elseif (Qt [il Ci80. O) mi] +=360.0>
>
Figure 3.27: Map the target positions for move functions
Setpoint buffer send controlles
\ J \
interrupt handlcr
Figure 3.28: C'ont rol structure
CHAPTER 3. IMPLEMENTATION OF A REAL-TIME COiVTROL SYSTEM 65
3.4 Summary
In this chapter we presented the detailed design and irnplementation of the real-time
cont rol system. The real-time system has been designed in the way which meets t ight
constraints. The three basic operations of a real-time system: sampling, processing,
and rrsponciing. miist be completed during the sampling interval.
The Q N X operating system was chosen over other operating systems because it
was designed for real-time applications. Also it is the ordy real-time operating system
supported by the CORBA technology that we use to integrate the real-time control
system with other heterogeneous platforms.
In Our test bed. PWM amplifiers were used for joint motor actuation. and quadra-
t ure encoder signais were used for position feed back. The systern provides position
control for at most 9 joints. A PID control algorithm was usecl for the control calcu-
fation.
The MFI03.A hardware was configured to interface the host PC ancl the servo
amplifiers by an ISA bus.
From the point of view of software engineering, the real-time software system can
be broken into three modules: the initialization, the controller, and the interface.
The initialization module initializes the software executables and hardware devices
of the MF10:3rZ controller. The interface module allows users to send commands to
the system, and to retrieve information from the system through the console. The
controller module performs the three major tasks of the controller. These tasks are:
encoder input, position set point calculation, and actuation output. The data and
operations were identified and designed for each of the three tasks. The next key issue
is to synchronize the three tasks by using the QNX interrupt ha.~dling mechanism.
The initialization module initializes the MFI03A hardware to get the addresses
and IRQs of the interface cards. This module starts up the digital [ / O channel
writing, encoder channel reading, and digital to analog conversion channel writing. It
generates the interval t imer for the synchronizat ion signal and the interrupt signal.
The initialization module also starts up the software executables including the data
server, setpoint server, and path planner.
The controller module was designed as an infinite loop which waited For the in-
terrupts to corne [rom the MFI03A hardware. The interrupt signals triggers the
controller to read the quadrature pulse signals from the nine encoder channels. The
encoder reading was developed in a way which prevented the encoder registers from
rolling over the range. In the background, the path planner executable cornputes the
position setpoirits. Ttie corit rollcr calculates tlie pusi tiuii errw between the actual
positions and the set points. The joint drive levels are computed frorn tlie position
error by the PID control algorithm.
The interface module was designed by using the UNIX curses functions. The
home and move functions have been developed to allow users to do position controls
from the console.
Chapter 4
CORBA Integration
4.1 Introduction
The Orbix [-21 implementation of CORBA niiddleware has been cliosen to build our
distributed systeni. Development of the distributed system çan be broken down into
t w o parts. the server program and the client program. Both programs will utilize
object-oriented design.
On the server side located on a PC operating under QNX, the real-time control
system is identified as an Orbix object. The attributes and niethods of the real time
control system are defined in a public interface using the CORBA Interface Definition
Language ([DL). Exceptions is also defined which can be handled at the server side
when they are caught at the client side. The operations in the IDL interfaces are
implemented with C++ classes in the server program by BO.AImp1 . .A niain server
program creates instances of the implementation classes and is bound as a proxy
object by client programs.
On the client side located on a PC operating under Windows NT. the real-time
control system is identified as an Orbix object. The public interface of the real-time
control system is compiled by using a CORBA IDL. The OMC IDL compiler generates
a client stub to define the proxy object. A client program is developed to get the Orbix
reference to the real-time control system, and to access the attribute and operations
as defined in the object's IDL interface. The Internet Inter-ORB (IIOP) protocol
is used for the Object Reqiiest Broker (ORB) communication instead of the Orbix
protocol. A method for error handling is also included in the client program.
4.2 Integrat ion
4.2.1 ORB Structure
The object request broker (ORB) structure in our rernote real-tirne system is illus-
trated in Figure 4.1. The CORBA defines a standard architecture for Object Request
Brokers (ORBs) (281. An ORB is a software itifrastructure that facilitates the commu-
nication between a program and an object which are located or1 two different hosts of a
network. The ORBs hide the underlying cornplevity of network communications from
the clients. The client program does iiot have to know comrniinication mechanisms
such as protocols. shared rnemory, local met hod calls. etc.
In our systern, the client program will call the meniber fiinctions of the real-
tirne control systern object. The client program can be on different hosts riinning
different operating systems, such as CVindows YT, QNX. or Sun Solaris. However,
this is dependent upon the availability of the CORBA IDL compiler and the C++ compilers. Two cases, in which the client program is located on PCs running Windows
NT and QNX, have been tested for this thesis project. The client program does not
need to know where the object is located or how it is implernented. When the client
prograrn calls a member function on the CORBA real-time system object. the call is
transferred through the client stub code to the ORB. The ORB refers to a database
called the Implementation Reposito y which checks the location of the object. Then,
the ORB passes the function call through the object skeleton code to the target object.
In this case, a static invocation method is used because the interface of the real-time
system object is known at the compile-tirne. If we wish to obtain information about
the object interface at run time, ao alternative approach, the Dynnmic I n vocation
In terface ( D I I ) , should be used ['Y].
CHAPTER 4. CORBA INTEGR.4TlON
repository 1 IDL 1 1 compiler
implementation repository
1 object request broker
Figure 4.1: ORB structure of the real-time remote system
CHAPTER 4. C'ORB44 INTEGRATIOiV
4.2.2 CORBA Interface
Behavior of Distributed System
The local real-time control system developed in tliis thesis project is Iocated on a
PC operating in QNX. The remote system is intended to expand the same real-time
control systern to a remote machinc that c m run QNX or other different platforms
across the Internet. It will enable other machines across the Internet to share the
resource that has been developed in the project.
The remote system should be able to achieve al1 the functions that the local real-
time control system is able to achieve. Icleally. the remote service should look just
like a local service. The f'ollowing behavior of the remote system was derived:
a The real-tiine controller server carries out the low-level cont rol tasks for rnulti-
joint robot devices. The serves coritrols the start and stop of the joint movement.
The server also controls the joint velocity change and position change.
The client application interacts ivith the real-time controller server via a CORBA
Orbix interface.
IDL Specification
Before the client program can access the server program. the client must kriow the
types of operations that are supported by the server and the associated data for
the operations, but no more. From an object-oriented view. a good interface should
separate the essential qualit ies of a system from the incidental implementat ion details.
On one hand, the essential qualities are more important and reusable then the code
used to implement them. On the other hand, a good interface makes it Feasible to reuse
the code developed on the PC running QNX. The interface for abjects are defined
in the OiCIG interface Definilion Language (OMC IDL) [49]. In our case, the Orbix
OMG IDL compiler was used. The OMG IDL is not a programming language, so it is
language independent. This forces separation of the interface and the implementation.
The interface design is similar to that of classes in C++. Figure 4.2 shows the interface
for the real-time remote system.
CHAPTER 4. CORBA INTEGRATfON
//IDL s p e c i f i c a t ion s t r u c t P o s i t i o n - j o i n t <
/ / t a r g e t p o s i t i o n s f o r n ine j o i n t s long pos-1; ...,
> stnict Veloci ty- joint{
/ / t a r g e t v e l o c i t ies f o r n i c e j o i n t s long vel -1 ;
i n t e r f a c e c o n t r o l l e r
readonly a t t r i b u t e Pos i t ion- jo in t f ina l -pos;
except ion Mot ionerror{) ;
/ / j o i n t motion opera t ions void home(in s h o r t vc ru i se , i n s h o r t amax); void move(in Pos i t ion- jo in t t a rge t -pos , i n s h o r t vcruise, i n shor t amax)
r a i s e s (Mot ioner ro r ) ;
Figure 4.2: IDL specification to real-time rernote system
CH.4PTER 4. CORBA IiVTEGR.4TION
The [DL definition specifies an interface called controller which supports three
motion operations: home, move, and spin. The home operation takes the cruise speed
and the maximum acceleration and returns the void type. The move operation takes
the target positions of nine joints, the cruise speed. and the maximum acceleration.
The move returns void type. Attributes indicate that variables are available in an
object and the client program can read or write them. In the real-time controiler.
the moue operation will move the joints to the required final positions. When the
final positions are reached, the actual positions will be obtained by encoder reading.
The client program can reacl the values. but cannot write them when the keyword
readonly precedes the attributes. The parameters carried wit hin the operations
have to be specified on their directions. The i n mode rneans the parameter is passa
from the caller of the operation to the object. The ou t and inou t define the opposite
direction and both directions. The parameter passing mode allows the [DL compiler
to nmp operations accurateiy to a target programming language.
The IDL operations can raise exceptions to indicate the occurrence of an error.
CORB A provides two types of exceptions:
0 Sgstem exceptions are defined by CORBA. They do not appear in an IDL spec-
ificat ion.
User-dejined erceptions are defincd by users in an IDL s~ecification [Z].
In the cont roller interface specificat ion, a mot ion error exception was speci fied. and
raised in the operat ion definition.
An interesting and useful feature of the CORBA [DL is the inheritance of inter-
faces [49]. If we have another object interface which also defines the operations and
associate data of the controller interface, we can define the relationship between the
two interfaces as inheritance. For example, the dextrous robot hand in the IRbIS
laboratory has force/torque sensors rnounted on the fingertips. If a force control is
required, a low-level mechanism must be used to achieve the proper update rate of the
control. We c m define force control as a inheritance interface, as shown in Figure 4.3.
Al1 of the data structures and services in the base controller interface will become
part of the inheritance force control interface. In addition, we can define new data
//IDL i n t e r f a c e c o n t r o l l e d
i n t e r f a c e v is ion,control : control ler{ f l o a t ge t \ -v is ion\_imageo ;
i n t e r f a c e sensor,control:contraller( f l o a t cal\,f orce\,f eedbacko ;
Figure -1.3: Inlieritance of IDL interfaces
structure and services in the inheritance interface that do not belong to the base in-
terface. For example, the c a l 2 o r c e f eedback will calculate t h e force feedback frorn
the sensor. If a vision servo control is required. an inheritance interface frorn the base
cont roller interface can be designecl.
Stubs and Skeletons
The stub code and skeleton code are generated by the [DL compiler [-SI. A head-
file c o n t r o l l e r . h h is shared by both stub code and skeleton code. The stub code
c o n t r o i l e r c . CPP is linked wit h the client program. The skeleton code c o n t r o l l e r S . CPP
is linked with the server program. From the point of view of data marshaling, the
stub is a prozy that binds the client to the server object and marshals parameters on
the client. The skeleton is an adapter that registers objects, activates objects, and
demarshals parameten on the server.
The shared header file c o n t r o l l e r .hh is sbown in Figure 1.4. LVe can see t hat the
CHAPTER 4. CORBA INTEGRATION
... class IT-DECLSPEC-controller c o n t r o l l e r : p u b l i c virtual CORBA::Object(: p u b l i c : t .
v i r t u a l P o s i t i o n - j o i n t final-pos (C0RBA::Envrionment %IT,env=CORBA::IT,chooseDefaultEnv()) throv (CORBA : : Syst emExcept ion) ;
v i r t u a l void home(C0RBA::Short vc ru i se , C0RBA::Shart max, C0RBA::Environment &IT,env=CORBA::IT,chooseDefaultEnv()) throw (CORBA : :Mot ioner ro r ) ;
Figure 4.4: Controller.hh
header file defines the data types and operations in the [DL interface in C++. Virtuai
keywords are used before the iunct ions. This means the stub code rvill automatically
invoke the proper rnember functions if there are inheritance interfaces. The Cf+
mernber function f i n a l p o s ( ) maps to the readonly attribute f inal-pas in the IDL
interface. The C++ home() member function maps the home() operation in the IDL interface. The C++ types CORBA: :Short vc ru i se maps the operation parameter in
the IDL interface. We notice that the [DL definition is similar to the C++ definition.
However, there are differences between these. First of all. IDL is not a programming
laquage. IDL supports the following features: modules, i n t e r f a c e s , methods,
a t t r i b u t e s , inheritance, arrays , , s t r u c t , enum, consts, and exceptions. How-
ever, it does not support d a t a members , p o i n t e r s , c o n s t r u c t o r / d e s t r u c t o r , ovarload
mathod, i n t , or template. A common use of pointers in C is to use a char pointer
to represent a char. Instead, s t r i n g type should be used in an IDL interface. The
mapped C++ classes have constructors, destructors, copy constructors, assignment
operators, dynamic binding with virtuai keywords, and exception handling.
CHAPTER 4. CORBA INTEGR44TION 75
#include<CORBA.h> c l a s s IT-DECLSPEC-controller con t ro l l e r -var : pub l i c cQRB~::-var{ p u b l i c :
cont ro l l e r -var () ; cont ro l l e r -var ( con t ro l l e r -p t r IT-p); con t ro l l e r -var (const con t ro l l e r -var BIT-s) (3) cont ro l l e r -var k o p e r a t o ~ (con t ro l l e r -p t r IT-p) ; (4) œcontrol ler ,var () ; (5) con t ro l l e r -p t r operator-> () ; (6)
Figure -1.5: >Iemory management
The class controï ler -var [23] is a helper class for class con t ro i i e r . The con t ro l l e r -var
provides help to manage rnemory associated with c o n t r o l l e r objects. Conception-
ally, a-var can be considered as an abstract pointer that takes ownership of the data
to which it points. Here, ownership means when an object owns a pointer. it has the
responsibiliiy for the things the pointer points to and the life cycle of the pointer. Un-
clear ownership will lead to memory leaking. The helper class is shown in Figure 4.5.
The default constructor (1) creates a control ler -var which has a nul1 pointer or a ni1
object reference. Constructor (2) creates a con t ro l i e r -var that has a pointer with a
parameter. The constructor will free the memory space when the object is destroyed.
The constructor (3) creates a deep copy of another controller object pointed by L I T S .
The overloaded assignment operator (4) frees the old data and makes a deep copy of
the object pointed by the IT-p. The copy will be destroyed when the controï Ier-var
is destroyed or a new value is assigned. The destructor (5) frees any data pointed by
the controller-var. The overloaded operator->() returns the controller-ptr but
still retains ownership of the pointer.
CHAPTER 4. CORBA INTEGRATION
include "controller.hhJJ include ciostream .h> int main(int argc, char *argv){ controller\,var controllervar; C0RBA::short v a;
... )catch(CORBA: : SystemExcept ion BsysEx) ( ~err<<'~systern exceptionJJ<<endl;
> t ryi
home(l0,10) ; )catch (CORBA : : Mot ionerror) { cerr<CJ 'home exceptionJ ><<endl;
>
Figure 4.6: Client program
4.2.3 Client-side Program
The functionality provided by the real-time control system is defined in the [DL inter-
face. The client program does not need to know how the lunctions are implemented.
Therefore, the client program focuses on how to use the functions. The first task.
that the client program needs, is to locate the target object across the network. Then
the client program will bind itself to the target object. The client program can in-
voke services on the target object after the binding. The code segment of the client
program is shown in Figure 4.6.
The member function controller: :bind(" :CtrlSrvJ >) [22] requests the Orbix
CHAPTER 4. CORBA INTEGRATION .
ORB to search for an object which offers the controller interface. The parameter
":CtrlSrvV tells Orbix to search for the required object in the CtriSrv server. The
parameter tells Orbix to search for the host with the name agrv CI 3 . In this case. the
client program is located on a PC running Windows NT, and the server is Iocated on a
PC running QNX. The server is not in the client's address space. Orbix will construct
a proxy for that object in the client's host address space. The -bind() function will
return a reference to the proxy object. The client program will assign a this pointer
to a controlier-var variable which manages the reference to the proxy.
After the client program is bound to the target object, the client calls operation
home() on the object. The operation will create a new controller object in the
server, and the operation rrturn value is a reference to the c o n t r o i i e r object. Oncc
the client obtains the object reference. it calls the controller operation home().
4.2.4 Server-side Implementation
In order to develop the server program, the following steps have been taken:
Provide a C++ class that includes member functions that match the operations
and attributes as defined in the [DL interface. Two approaches, BOAImpl and
T I E can be used [BI.
0 Create the implementation objects for the interfaces
Make the implementation objects available to the clients.
Inheri tance and composition descri be t wo different concepts in ob ject-oriented pro-
gramming. Bot h inheri tance and cornposi tion enable the iisers to reuse the available
code. In the inheritance case. the derived class must have ail the characteristics of
the base class. In the composition case, the new class does not necessarily have al1
the characteristics of the old class. For example, a force control object has al1 the
functions of a controller object. So a force controller can be an inherited class from
a controller class. In other words, everything that a controller class supports will be
supported by a force controller as well. If sorne functions supported by the controller
CHAPTER 4. CORBA IVTEGRXïIOiV 78
/ / f i l e "contro l1er , i .hH # i n c h d e " c o n t r o l l e r . h h J ' c l a s s c o n t r o l l e r - i : pub l i c control lerBOAImpl~ public :
//ct o r ; / / d t o r ; v i r t u a l void hame(C0RBA::short v , C0RBA::short a,
C0RBA::Enviroment &enc);
Figure 4.7: Implenient server using BOA Impl approach
class are not siipported by the force controller class, the inheritance relationship is
not appropriate and the composition approach needs to be used i f the user wants to
reuse the cont roller code.
The implementations using the BOhImpl approach and the TIE approach are il-
lustrated in Figure 4.7 and Figure 4.8. respectively. In the BOAImpl approach. the im-
plementation class c o n t r o l l e r i is inherited from the base class controllerBOAImpl
which is generated automatically by the IDL compiler. Also. in the TIE appoach. no
virtual keyword is used because it is not an inheritance class and there is no dyriamic
binding in this case.
The TIE-controller ( c o n t r o î ï e r i ) ['23] construct is a preprocessor macro cal1
that expands to the name of a C++ class, which represents the relationship between
the c o n t r o l l e r and c o n t r o l l e r i classes. DEF-TIE-controller ( c o n t r o l l e r i is a
macm. The macro has a constructor that takes a pointer to a c o n t r o l l e r i object
as a parameter. Consider an IDL operation home(). In the IDL CC+ class. it is
translated into a function which returns a pointer c o n t r o l i e r p t r . However, using
the TIE approach, the actual object to which a reference is to be returned would
be of type c o n t r o l l e r i . This is not a derived class of controiier. To solve this
CHAPTER 4. CORBA INTEGRATlON
//file "controller-i.h" #inchde "controller.hhn class controller,i( public :
//ctor ; //dtor ; void home(C0RBA::short v, C0RBA::shor-t a, C0RBA::Environment &end;
DEF,TIE,Controller(Controller,i); //Now we have a class TIE,Controller(Controller,i)
Figure 4.8: Implement server using TIE approach
CHAPTER 4. CORBA INTEGRATION 80
problern, the TIE approach will create an object type of TIE-controller (controlleri).
The TIE-controller (controlleri) is a derived class of c o n t r o î l e r . The TIE object
will reference the c o n t r o l l e r i object, and a reference to the TIE object should be
returned by the function. So the server creates two objects, c o n t r o l l e r i object.
and a TIE object 1-31.
When the server is designeci, two objects are created, c o n t r o l l e r l aiid a TIE
object. The server will use the TIE object instead of the c o n t r o l l e r l .
4.2.5 Server Main hinction
The server main() programs using BOAInipl and TIE approaches are shown in Fig-
ure 4.9 and Figure 4.10. respectively. The main() function creates an implementation
object of the type c o n t r o l i e r . The implementation object is available to al1 Orbix
clients which have a reference to the object. In the BOAImpl approach. the code
uses the nev function to allocate the memory space for object c o n t r o ï l e r i . and
then it uses a default constructor con t ro l ï e r -var as shown in Figure 4.5 to initial-
ize the object. In the TIE approach. the code uses a new function to create two objects.
c o n t r o l l e r i and a TIE object. Then the server calls CORBA: : Orbix. i m p l i s r e a d y ()
to indicate that it has completed the initialization and the C0RB.A clients can send
requests to i t. The CORBA : : Orbix . i m p l i s l e a d y () does not ret urn imrnediately.
Instead, it blocks the server until an event occurs. It then handles the event and
re-blocks the server to wait for another event to occur. When the server is launched
by the command putit, the server name is known to the Orbix daernon by the first
parameter of the function impl i s zeady( ) . The i m p l i s s e a d y ( ) returns when a
timeout occurs or an exception occurs while waiting for requests lrom clients. The
timeout between the two events can be changed.
Before the server can be used, it has to be registered by the Orbix Implemen-
tation Repository The Implementation Repository records each server's name and
executable code file name.
The runtime structure for the system is shown in Figure 4.11.
CHAPTER 4. CORBA INTEGRATION
main() ( //create a new controller-1 object. Controller-var cVar = new Controller-1;
//wait for incoming requests CORBA: : Orbix . impl-is-ready ( " C O ~ ~ N " ) ;
3 catch ()
Figure 4.9: Irnplement server main() using BOAImpl approach
//C++ #inchde "controller .hh"
//create a neu controller ob j ect . Controller-var cVar = new TIE-controller(controller-I)(new controller-1); Try C / h a i t for incoming request s
CORBA : : Orbix . hpl-is-ready("~onsrn") ; > catch()
Figure 4.10: Implement server using TIE approach
- - - - - - - - - - - - - - - I I l I I y 3 1 1 f \ motor I I
client program -bind() '
orbix daemon f \ t ,,,,--- 1 -,----- 1- encoder I I I l
I I 1
contdler server - r - -
I I I I
client host running Windows NT Real-tirne control servcr host ninning QNX
Figure 4.1 1 : Run t ime structure for the real- time remote system
IIOP vs POOP
The different implementation between different Object Request Brokers (ORB) raises
the issue of ORB lnteroperability. ORB interoperability allows a client of one ORB to invoke operations on an object in a different ORB via an agreed protocol. The
standard protocol of ObIG is called the Cenerd Inter-ORB Protocol (GIOP). The
GIOP assumes that the nature of the transport layer is connection oriented. The
GIOP defines the data representation and message format. The OMB defines a spe-
cialization of GIOP that uses TCP/IP as the transportation layer. The specialization
is called the Internet Inter-ORB Protocol (IIOP) [%]. The GIOP defines a transfer syntax known as Common DatiZ Representation
(CDR). The C D R defines dl the data types: basic types, structured types, object
reference and pseudo-O b jec ts.
The GIOP also defines seven message types. .A common message includes a header
and a body. The header includes the message size, a version nurnber, the byte ordering
and message type. Different types of messages are:
Request
A request message is sent by a client to a server. It encodes an operation
invocation that includes the identity of the target object, and an identifier that
is used to match a Reply message to a Request.
Reply
A Reply message is sent by a server to a client. It encodes an operation invoca-
tion resporise including in and out parameters and exceptions.
Cancel Request
A CancelRequest message is sent by a client to a server in order to cancel a
request.
LocateReques t
.A 1ocateRequest message is cised to fincl the location of a remote object when
an operation invocation has many parameters. It will determine if the target
object reference is valid.
Locat eReply
CloseConnect ion
A CloseConnection message is sent by a server to notify the client that the server
will close the connection.
MessageError
A MessageError message can be sent by a server or a client if it has received a
message that has an unknown message type or version number.
The mapping of the GIOP message transfer to TCP/IP connections is called the
Internet Inter-ORB Protocof (HOP). The HOP identifies an object by an lnteroperable
Object Referenee ([OR). The format of an [OR includes an ORB'S interna1 object
reference, an Internet host address and a port number.
The Orbix supports the Plain Old Orbix Protocol (POOP) and HOP. The Orbix
on the host running QNX uses the Plain Old Orbiz Protocol (POOP) for client-server
communication by default. The Orbix on the host running CVindows NT uses the
Internet Inter-O RB Protocol (IIOP) as the default protocol. These two different
protocols will allocate different Internet TCP ports for themselves. So when the
client prograrn invokes a method frorn the server, it sends the message through an
IIOP port. However, rvhen the real-time controller server is launched, it uses the
POOP port. The server is trying to iistening to one port, but tlie clieiit is tryiiig tu
talk to the server [rom another port. .As a result, the methods can not be invoked,
and the server will throw an exception that says time is out.
For our real-time remote system. two ways can be iised to solve this problem. The
first way is to force the client program to use the POOP protocol instead of the HOP
protocol by adding the following commancl in the client program:
COR%A::Orbix.bindUsingIIOP(O).
The same protocol is used to let a client know about the IOR of a server. The
other way to get around tliis problern is to corivert the IO R to a string ancl write it to a
file. Then the client can find the server by reading the string value. The code segment
for the server program is shown i t i Figure 4.12. The function -abject-to-string()
returns the Orbix Form of an object reference. To publish the string form of the [OR. the string needs to be written to a file that can be accessed by a client.
The client program accesses the file and reads the string form of the 10R. Then
the client can transfer the string to a n object reference of CORBA type by using
the funct ion CORBA : : ORB : : string-t O s b j ect () . The interoperable object reference
returned from string-to-object needs to be narrowed to an object reference of the
appropriate interface before operations can be invoked. The client code segment is
shown in Figure -1.13.
CHAPTER B. C'ORBA ~IVTEGRATION
//c++ //Server code. //If using s t a t ic libraries , use macro #define USE-IIOP ... main() (
//create a controller ob j ect Controller-i mycontroller; char* str0b j ; t ryC
strObj=mycontroller._object~to~string(CORBA::IT_INTEROPERABLE~OR~KIND); > catch(. . .).; //vrite the string name into a file that a client program can access ... //tell Orbix that the server initialization is ready
Figure 4.12: Use IIOP in the server program
CllAPTER 4. CORBA INTEGRATION
//c++ //Client code. / /If using s t a t i c l ibrar ies , use macro #define USE-IIOP
S . .
main() ( CORBA: : ~ b j e c t \ _ p t r objPtr; controller\_prt myctlptr; char* ref String; . . . //read t h e s t r ing of the reference f rom a f i l e . . . / /get the obj reference t ry
objPtr=CORBA: :Orbix. -string-to-object (refstring) ; > catch(. . .); //narrov the obj ec t t ry(
myctlPtr = controller: : -narrov(obj ~ t r ) ; 1 catch{. ..); //Invoke operat ions
Figure 4.13: Use IlOP in the server program
CHAPTER 4. CORBA IiVTEGRATION
4.3 Experiments
4.3.1 Measuring Time
The time factor is critical for a real-time control system. The overhead tirne generally
decornposes to two sources for this real-time networking control system. The time on
data input, data process. and data output of the real-time control system is one of
the important factors. The other one is caused by the cost of using CORBA Orbix.
Generally, the upper lirnit tirne for a real-tirne systeni is no greater than the sampling
time. The experiment measures the performance of the real-time control system and
the CORBA integration. First, the approximate upper limit time of a control loop is
measured. Second, tlie approximate overhead time to invoke an operation across the
network is measured.
4.3.2 Experimental Setup
We set up a CORBA Orbix ORB in our test bec! to perform tlie measilring-timing ex-
periment. The underlying communication channel is Et hernet. Both PCs are locatecl
on the subnet of Simon Fraser University, CSSnet. About 65 Sun Workstations and Y Ethernet subnets are connected to the backbone of CSSnet. The PCs are as follows:
One Intel Pentium 90 MHz workstation running QXX 4.25 with the Orbix 2 3
and running the real time control system server:
One Intel Pentiuin II '238 MHz workstation running Windows NT with the Orbix
2.5 and running the client program.
To rneasure the time factor in the real time control system, a tirne measuring
function was added into the controller process. The time factor critical to a real tirne
system performance is the time lapse between the encoder input and the DAC output.
The funct ion in Figure 4.14 was added between encoder reading and DAC writ ing:
The Watcom C/C++ compiler provides a function clockgett ime (CLOCKREALTIME,
&tirne) that is used to get the current time [:34]. However, we found the time to do
CHAPTER 4. CORBA INTEGRATION 813
struct timespec s t a r t , stop c l o c k g e t t ime ( CLOCKREALTIME , &st art ) ; for ( i = O ; i<n; i++) //encoder reading //. . . //DAC vrit ing
c l o c k g e t t ime( CLOCKREALTIME, &stop) ; Duration = ( s t o p . t v s e c - s t a r t . t v s e c ) + ( s t o p . t v s e c - s t a r t . t v s e c ) / BILLION;
Figure 4.14: blemure the cont roller overhead t ime
one loop between the encoder input and the DAC output was too srna11 for the time
function to measure. As a result. a large number of control loops. n loops. w here n
is a multiple of LOO to 1000. were rneasuretl. The timing results include the time ta
do n times of encoder readings and DAC writings. The upper limits of the timing
results for the control loop were sufficient to measure our real-time control system
performance. This approach, therefore, was adopted as the method CO evaluate the
system performance.
To evaluate the performance of the remote operation method, a dummy method
function was added to the server side code on the PC riinning QXX. The time to do
an aperation on the server side should be eliminated in order to obtain the overhead
time to invoke the operation. Thus. a dummy function was added as follows:
void c o n t r o l l e r : :dummynethod () { return; }
The dummy function waits for a rernote function cal1 and returns a signal to the
calling client when it is invoked.
An experiment was carried out to measure the overhead time to invoke the dummy
funct ion from the client on the PC running Windows NT. A timing funct ion was added
CHAPTER 4. CORBA INTEGRATION
start = clock() ; //invoke the dummy function for(int i=O ; i<n; i++) { controllervar->dmy () ;
1 finish = clock() ; duration = (float) (finish - start) * 1000 / CLOCKSSERSEC; cout<<"start is "<<start<<endl<<"finish is "<<finish<Cendl; cout<<"duration is "<<duration<<endl;
Figure 4.15: Invoke durnrny fiinction from Mkiows NT
in the client code is shown in Figure 4.15.
The timing function in Visual Cf+ gives the clicks of the PC interna1 dock.
The time resolution is 10 milliseconds when using t his function. An experiment was
conducted to measure the overhcad time to invoke the dummy fiinction which \vas
repeated for n times.
An experiment was carried out to measure the overhead time to invoke the dummy
function from a client which was also on the PC running QNX. The time to invoke
the dummy function in one loop showed that the timing results consisted of two
values t hat occurred irregularly. Flirt her ex p i m e n t s were performed to measure
the overhead to do repeated invocations. A timing function was added to the client
code on the PC running QNX, on which the server code was located. The code in
Figure 4.16 represents the additional timing function.
The values of stop. t v s e c and start . t v s e c would be ovedow because of the
9-digi ts-nanosecond value when the invocation of the dumniy funct ion is repeated
more than 500 times. A simple way to prevent overflow from happening is to change
the unit of s t o p . t v s e c and start .tvsec from nanoseconds to microseconds.
CHAPTER 4. CORB.4 INTEC~R,-ITlOtV 90
struct timespec s tar t , stop c l o c k g e t t i m e ( CLOCKREALTIME , t s t art ) ; for (i=O; i<n; i++) ( cont rollervar->dummy () ;
1 c l o c k g e t t ime ( CLOCKREALTIHE, &stop) ; Duration = (f loat) ( stop. t v s e c - start . tvsec ) * 1000000000 + (stop. t v s e c - start . t v s e c ) ;
Figure 4.16: Invoke dummy functiori Q N X PC
The overtime ta invoke t tie dummy function coiiltl include otlier costs besides
C'ORBX Orbix. A possible cost coiilcl be the overtirrle to do empty loops. Thus.
experiments were done to measure the time to do empty loops as follows:
for(i=O; S n ; i++){ ; } .
4.3.3 Timing Result s
The timing results obtained for the real time control system are given in Table 4.1. The
approximate average delay time results for one control loop are shown in Table 4.2.
Timing results to invoke a dummy method hosted on the QNX server from the
NT client are shown in Table 4.3. Timing results to invoke dummy method for n
times from a NT client are shown in Table 4.4. The approximate average timing
results obtained h m Table 4.4 are shown in Table 4.5. Timing results to invoke a
dummy method from a QNX client are shown in Table 4.6. The data in Table 4.6
show t hat two results, O and 9.999315 rns appearing in a irregular way. Table -I.?shows
the frequency wit h which the result 9.999315 occurs over 1.50 trials. Timing results
to invoke a dummy function for n times are shown in Table 4.8. The approximate
average timing results are shown in Table 4.9. Timing results showing 500 empty
loops and 1000 ernpty loops on the NT PC and the QNX PC are shown in Table 4.10,
CHAPTER 4. CORBA INTEGRATIOiV
and Table 4.11.
Table -1.1: Controller time for n control loops (in ns)
4.3.4 Analysis
t 5
119991096 229984140 3399'76'704 449969 184 569960960 679953-LOS 'EN9452 16 909937'664
Latency is the lapse time from the occurence of an external event to the actual ex-
ecution of code within the program which is reponsible for reacting to that external
event. Latency should be minimized to obtain the maximum real-time performance.
Several forrns of latency have been encountered in the real-tirne networking system.
t 4
1199917'76 239983552 349976032 449969 184 569960960 679953408 ï99945216 909931664
Cont roller Latency
t 3
'129991096 229984240 349976032 459968480 569960960 6'1995:3408 ïW9452 16 909937664
n loop IO0 200 300 400 500 600
1
700 800
Table 4.2 shows that the upper limit of the average controller time is 1.15 rnilliseconds.
The cont roller t ime consists of several factors.
Binding Latency
t1 129991096 229984240 339976704
Table 4.5 indicates that the average time to invoke a dummy function was 8.83 ms
when the server code was on the PC running QNX, and when the client code ivas on
the PC running Windows NT. The overhead time was caused hy the establishment of
the connection between t h e server and the client using the -bind()call. When a client
t 2
119991776 229984240 3499'76032
459968480 569960960 6899.52704 799945216 909937664
459968480 569960960 6199*5340S 759945856 909937664
CHAPTER 4. CORBA I!VTEGR-ATION
1 n l o o ~ 1 f in nanoseconds 1 5 in milliseconds 1
Table 4.2: Approximate cont roller time for one control loop (in ms)
calls interfaceName: : bind( ' 'marker: Server' ' , ' 'host ' ' ), the Orbix wili check
if a proxy already exists in the client's address space for the target object. If there is
no exist ing connect ion bet ween t lie client and the target server, ITPING () fiinct ion
will send a message to the remote daemon. CORRA tlien calls getIIOPDetails()
on the Orbix daemon to obtain the port nuniber on which the server will be listening.
Next, a connection will be establishecl between the server and the client. And finally.
ITSING() will send a standard IIOP message, LOCATEREQUEST, to the server
to verify the target object.
Context Switching Latency
Table 4.9 shows t hat the average time to invoke a dummy function is 4.18 ms when
the client code and the server code were located on the same PC running Q'IX. A
CORBA invocation involves the interactions between the client and the server, e.g.
sending a request (client side), receiving a request (server side), sending a reply (server
side), and receiving the reply (client side). When the client and server are located
on the same host, al1 four processes are emcuted by the host processor. When the
processor is switched frorn one processor to another, the state (processor registers
and associate data) will be saved. Then the systern will load the saved state for the
I ) start tick 1 stop tick II t
Table 4.3: Time to invoke a dumniy lunction once froni NT (in ms)
new process because later on the previous process will be restarted and will continue
as though there was no interruption. Thus, the contex-switching overhead time was
included in the experiment.
Marshaling Latency
The number of arguments to invoke a method could make a difference in overhead
tirne. The cost to marshall and unmarshall an object's state in order to transmit the
object across a network would Vary with different size objects.
Page Swapping Latency
Another important factor is virtual memory management. When the state of an
object is cornplex, it will also cause page swapping at the operating system level.
Page swapping involves the disk I/O that will significantly slow down the process
speed.
CHAPTER 4. CORBA lNTEGRATlON
Table -1.4: Time to invoke a dummy function for n times from NT (in ms)
n loop 100
Figure 4.17 shows that the CORBA invocation over the Internet cost more over-
head time than the invocation from the local machine dici. Both invocations cost
more overhead time than the tirne spent on the controller process.
t 821
t 2
891 h 941
t 4
861 t 5
921
-
t 88'7
CHAPTER 4. CORBA UVTEG'RATION
Table 4.5: hpproxiniate tirne to invoke a dunimy function once frorn XT (in ms)
Table 4.6: Time to invoke a dummy function once lrom QNX (in ms)
Table 4.8: Time to invoke a dummy function for n times from NT (in ms)
n loop 100 200 :300
t i 419.971 i329.943 1259.91
t 2
419.971 819.943 1259.91
t 3 429.971 8:39.942 1259.91
t.4 419.971 8'29.943 1159.91
t s 419.971 849.942 1249.91
t -421.971 835.942 1257.91
CHAPTER 4. CORBA INTEGRATION
1 n ioop ) t I
Table 4.9: Approximate time to invoke a dummy function once from QNX (in ms)
Table 4.10: Time to do 1000 empty loops on NT (in ms)
invocation 0
frum NT
inv ocalion
from QNX
Figure 4.17: Controller overhead time, invocation overhead time [rom local QNX PC, and invocation overhead time from remote XT PL
CHAPTER 4. CORBA INTEGRATION
4.4 Summary
In this chapter, we presented the real-time control system integration with the Win-
dows NT platform across local high speed network. We also presented the experirnents
conducted to evaluate the system performance.
The object reqitest h r o k ~ r (ORB) ronsists of the PC riining Q N X OS with the
real-time control system, the PC riiiiing Windows NT OS with the client prograni.
and the local Ethernet. When the client prograrn makes a function cal1 of the reai-
time system, the call is transferred through the client stub code to the ORB. The
ORB refers to the implementation repository to locate the distributed object. The
ORB passes the call through the object skeleton code to the target object.
.A CORBA interface is defined by using the OMC IDL. The interface defines the
types of the operations (homing and moving) which the real-time control system
server supports. The interface design is object oriented which seperates the essantial
and reusable qualities of the system from the implementation details. The interface
for the control system can be expanded to other similar control systems by using of
inheritance of interface.
The client stub code is a proxy that binds the client program to the control server
object and marsharls parameters on the client. The control server skeletion code is
an adapter that registers objects, activates objects, and dernarsharls parameters on
the server. The client-side program is developed to bind itself to the target object
and to use the operations that the control server provides.
The server-side program provides a C++ class of the control system that matches
the data and operations as defined in the IDL interface. The server-side program
creates the implementation object by using the inheritance-based rnethod or the
composition-based method. In the inheritance-based approach ( BOAImpl), the im-
plernentatioo inheri ts from the generated skeleton code. The implementat ion using
the cornpositon-based appoach (TIE) does not have virtual functions because it does
not use inheritance. The server main program creates an implernentation object of
the control system type. Using the BOAIImpi approach, the main program creates
one object. Using the TIE approach, the main prograrn creates two objects.
The CORBA Orbi': used by the QNX PC uses the plain old orbix protocol
(POOP). The CORBA Orbix which is used by the Windows NT PC uses the In-
ternet inter-ORB protocol (HOP). To make the client and server programs cornmu-
nicate wi t h each ot her, the interoperable object reference (IOR) of the server object
is converted into a string that can be read by the client prograrn.
The experirnents coriducted to evalua~r tlir systriii perluriiiarice ineasure the la-
tency of the control system, the latency of the CORBA function call from the local
Q N X PC, and the latency of the CORBA function call from the Windows NT PC
across the local high-speed network. The average approximate iipper limit of the con-
trol system latency is around 1.15 ms that is well below the sampling interval of 2 ms.
The average approximate latencies of CORBA fiinction calls from the local QNX PC
and the Windows NT PC over the Ethernet are 4.2 ms and 8.9 ms. respectively. The
latencies of the networked control system include controller latency. binding latency.
context switching latency, marshaling latency, and page swapping latency.
Chapter 5
Conclusion
The research describecl in this thesis has contributed to a real-time robot control
system using LIFI03A hardware running under QNX operat ing systeni. The research
has also contributed to an integration methodology for the real-tinie systeni with
processes or programs running under Windows.
Multi-joint robot systems (with up to nine joints) can use the real-time control
system developed in t his thesis to achieve position cont rol provided t hat MF IO3.A
hardware and QNX are utilized. The real- t ime cont rol system provides researchers
with the functions to carry out further high-level design for multi-joint robot systems.
To operate the reai-time control systern lrom the applications or processes running
on a different host with Windows NT across a high-speed network, one can use the
CORBA based approach that was developed in this thesis.
QNX provides determiiiistic contert switching time. interrupt latency. and mini-
mizes systern overhead for response to external events that are necessary for a real-time
system. The MFIO3A hardware provides digital to analog conversion and encoder
reading facilities and a set of software executables which allow the developer to avoid
register-level prograrnrning. Based on the QNX message-sending mechanism and the
YF103A facilities, a control system was designed and developed. The research in-
cludes control structure, hardware configuration, and high-level software (data struc-
ture and software module) design. The high-level software design was implemented
using C prograrnrning language and the QNX interprocess communication mechanism.
To allow other applications running on a Windows NT platform to use the con-
trol system, an IDL interface of the operations and associated data supported by the
control system as defined in IDL was written and deployed under QNX and Windows
NT. A server program was designed to instantiate objects that implement the IDI, interface. A client program was writteri to make function calls to the server object
through ORB. These implementations provide a basis for application interoperability
by alloiving one applicat ion/process to access the AP I of anot her dist ributed applica-
tionfprocess located on a heterogeneous platform.
The run- t ime performance of the real-time cont rol system was investigated by mea-
suring the appro'cimate upper limit overhead time of the control Ioop. The average
overhead time was found to be L . 1 5 milliseconds which is below the sampling inter-
val const raint. The run-time performance of invoking the funct ions of the real-time
control system ORB was investigated by measuring the approximate overhead time.
The average overhead time to make a function cal1 was found to be S.S milliseconds
between a QXX PC and a LVinclows NT PC across a local higli-speed rietwork.
CVe recommend the following possible future researcli direct ions based on the re-
search results and experience of this thesis:
Incorporate a simulation program on the \iVindows XT platform to do off-line
simulation of the robot. Many simulation tools are available for Windows NT
p9j.
0 Incorporate a vision system running on a Windows .UT platform to provide
visual feedback to the control system. One could also implement a video camera
for teleoperat ion.
0 Investigatetheuseofan .~TiCIswitchtoincreasethebandwidthandspeedofthe
local network and to implement a distributed real-time robotic control system
[15, 161.
Appendix A
Hardware Device Configuration
Figure -1.1 shows the hardware device configuration. The MFI03A interface card is
connected to a 4Y6 host PC by a 16-bit ISA bus.
r
PC mning
QNX OS
Figure A. 1: Real-time system hardware
servo amplifier 1
An 80-pin connector is used to connect the MFI03.A interface card and the con-
trolled system ['XI. The top row of the connector [row A ) provides connections for the
three channels of digital to analog conversion and the twenty-four digital 110 ports.
The bottom row (row B) provides the connections for the three channels of quadrature
encoder input and the SYNC and WDOG signals. A dual 40-pin ribbon cable is used
to connect the MFI03A hardware and the controlled system. The separate ribbons,
servo amplifier 2
...... .**.*.
f 3
servo mplificr 9
I I
IS A
bus i. J
A
DAC 80 pin
4
used for rows h and B, allow the possible high frequency digital encoder signals to be
kept from the sensitive analog out put lines.
The pinout for the connection between one joint and the hIFI03A interface card
is shown in Table A.1. The pin-1.4 is the digital to analog conversion (DACI) and
the output voltages are referenced to the analog ground (AGND) which is the pin-%\.
The pin-15A is one of the eight digital I f 0 lines on the port A. The 110 line voltage
is referenced to the digital ground signal ( C N D ) which is the pin- L3A. The II FiO3X
interface card can supply +5V or + I N to the encoders. The pin- 1 B is used to supply
+5V to the motor and it is referenced to the pin-2B (GND). The encoder channel is
provided with inputs for the encoder A, B, and Z phases from pin-13B. pin-l5R. and
pin- 17B. respectively.
The M F IO:IA interface card supports encoders wi t h t hree configurations: differ-
ential, single ended totem pole. and single ended open coilector output [32]. Each
encoder channel is configured by insert ing or removing a combination of jiimpers
and single in-line package (SIP) resistor networks. An encoder jiimper setting on the
iLIF103A card was chosen for the SV encoders with single-encled totem-pole configura-
tion as shown in Table A.?. The single-ended totem-pole input configuration provides
a less costly encoder connection. but is more sensitive to noise and cable length.
The MFI03A card uses the 82C5.L programmable interval timer to provide both
a programmable interval timer and a watchdog timer. The three 16-bit coiinters of
the YX54 are configured in Figure A.?. The counter O and counter 1 are cascaded to
form a 32-bit auto-reloading coiintdown tirner driven by the 6.33 MHz ISA bus dock.
The counter 2 is used as a one dot 16-bit countdown timer.
The encoder inputs of the WFI03A card have a digital noise filter section which
rejects noise on incoming quadrature signals. The noise filter uses a Schmitt trigger
and a three-clock-cycle delay filter to reject both low level noise and large short
duration noise spikes [3'2].
The PID filter on the MFI03A card provides features to reduce saturation. The
output of the integration is limited by a saturation block. The block limits the inte-
gration output to plus or minus a maximum value as specified by the user in the data
server's init ialization file. Users can also reset the value with the data server function
Table h.1: Encoder settings on LIFIOJX card: XC.= no connection
row B +5 CND N.C. A l N.C.
pin 1 2 ... 1 3 ...
Table A.?: Encoder settings on SIFIOJA card
row A DAC1 AGND N.C. GND N.C.
PIDwindupSet. The output of the filter also has a saturation block. The saturation
block will limit the filter output to plus or niinus a maximum value as specified by
the user in the data server initializat ion file. The user can also reset it with the data
server funct ion PIDsaturat ionset [ 3 11.
Rd OUT
R7 OUT
R9 ' IN
J P l l I'J
Encoder Single-Ended Totem-Pole +5V
JPlO OUT
to SIWC and Limer interrupt Iogic
interval timer watchdog timer
Figure A.2: Interval timer and stopwatch timer
Appendix B
Encoder Interface
The encoder preload fiinction must write the encoder output into the encoder preload
registers. The read and write functions are not carried out directly into the encoder
counter registers, because there would be a confiict of data storage if the read and
write funct ions cvere executed repeatedly. Instead. encoder latcti registers and en-
coder preload registers are attached to the encoder counter registers as indicated in
Figure B.1.
When the pulse signals are read. the encoder latch latches the encoder count on
a synchronization signal generated by the interval timer. The encoder latch remains
unchanged until a new synchronization signal arrives. In this way. the reading of pulse
trains of multi-joints can be synchronized because the synchronization signal will go
to the encoder latch for al1 joints.
When an encoder count needs to be written, the encoder preload registers will be
loaded to the encoder counts. There are two ways to manipulate the preload registers.
The preload registers can be loaded by the software preload bit. or by the index pulse
of the encoder.
APPEiVDIX B. ENCODER INTERFACE
read
1 encoder Intch synchronization signal
1 encoder counter upldown from rncoder logic
1 encoder preload 1 software preload
- encoder index
- preload enablddisable wnte
Figure B.1: Encoder read interface
Appendix C
MFIOSA Hardware Initializat ion
The MFI03Ainit fiinction is called to initialize al1 the MFt0:I.A cards in the back-
ground. The MFI03Ainit function will return the serial number. card select number,
assignecl base address. aiid assigned IRQ. 'The data are stored in an array so that
lihrary functions can find each card. The two MFIO3A car& used in t h e test bed
had values that were returned by the MFIO3Ainit function. as shown in Table C.1.
Table C.1: Initializing the bIFI0:lA cards by using MFIOJAinitfunct ion
hf4.er the MFI03A card server is initialized. several other steps need to be taken
for the card. Since the encoder preload registers could store old encoder values, the
encoder registers need to be set to zero. The functions e n d r i t e and encWriteAll
are used to write the encoders. Notice that the data are written to the encoder
preload registers instead of encoder counters. The preload registers, t herefore, need
to be loaded to the encoder counter registers. To latch the preload registers, the
encSof tPreload and encSof tPreloadAU functions are used. The DAC channels on
the MF103A boards could also have stored old values. The DAC channels need to be
cleared before they are used. In oder to set DAC channels to zero. the D A C w r i t e and
IRQ , 11 12
base address Ox3e0 0x230
card 1 card 2
serial number 26 1 1960822 '241 1961:314
the DACwriteAll functions are used. DAC channels are written by a 16-bit signed
value (from -32768 to 52767) that corresponds to the DAC voltage output rate from
-10V to + 10V. The syrichronization signal is activatecl by the function SYNcsoftO. On one
board, the SYNCsoft function generates an active low TTL pulse with a minimum
width of i00ns. The SYNC sigiial tr ieers ~tie latcli of DAC sigiial to the D I A converter, and the latcti of encoder signal to the encoder channels. The SYNC signal
on board is transferred to other two boards through a cable. This is the method to
synchronize the three MFI03A boards.
The 82C5.L programmable interval timeron the .1IFI09h card is loaded to generate
the interval timer for the program. PIDload() function is iisecl to load a count
necessary to generate a timer interval. Valid intervals for the S2C5-4 is between 0.25 ps
and 5 1.50 S. The value of 2 ps is chosen for the program. Then. al1 t lie synchronization
signals s hould corne lrom t his interval timer.
The interval timer provides services for synchronization and interrupt. The 'rIFI03A
card can generate four types of interrupt: 1) the programmable interval timer: 2) the
SYXC signal; 3 ) the digital 1/0 port B: and 4) the digital 110 port C. Interrupts
from these individual sources can be enabled or disabled. Only the programmable
interval timer interrupt is tised in our project. so the other three interriipts shoiild be
disabled. The function iruptDisable(base~ddr , PITI SYNC 1 PORTB 1 PORTC I } is used
to rnake sure they are disabled.
The [/O ports are initialized to provide the output channel for DAC signals. The
MFIOSA card provides %bit digital 110 ports. It consists of three 8-bit ports. A, B,
and C. Port C can be divicled into two 4-bit ports Clo and Chi [42]. Each port can
be programmed to be an input or an output. We chose the 110 port h to enable the
amplifier that drives the motors. The configuration of the digital 110 ports is shown in
Figure C.1. The functionDI0conf ig() is used to preform the I/O port configuration.
Port A is set to OUTPUT, port B, Clo and Chi are set to INPUT. The data to be written
are passed as an &Dit value.
#define A-INPUT tdefine A-OUTPUT #define B-INPUT #define B-OUTPUT #define CLOJNPUT #def ine CLO-OUTPUT #define CHI-INPUT #define CH1,OUTPUT
Figure C.1: XIFI03h digital 110 configuration
Bibliography
[LI Auslander, DM.. and Tham. C H . . Real- Time Software for Control. Prentice
Hall. Englewood Cliffs, XJ, 1990.
(21 Bach, M. J., The Desigrr of the WI.Y Operating Systern, Preiitice Hall. Englewood
Cliffs, NJ. 1986.
[3 ] Barabanov, M.. .4 Lin ur-based Real- Time Op r d ing Sptern. Master's Thesis.
Dept. of Computer Science, New SIexico Institute of Sfining and Technology.
June 1997.
[4] Bennett. S.. Red- Time Computer Control. 2nd ed.. Prentice Hall. Englewood
Cliffs. NJ. 1994.
[*5] Bernstein. P.t\.. *&IidcIleware," Comnuniccttions of the .-ICAI. Vol. 39. No. 2..
1996, pp. 86-98.
[6] Birrell, A D . . and Melson, B. J.. "Irnplementing Remote Procedure Calls." A CLCI
Transactions on Cornputer Systems. Vol. 2, NG. 1. February 1984, pp. 39-59.
[7] Bloomer. J . , Power Progmmrning urith RPC, O'Reilly L .Associates Inc. Sc-
bastopol, 1992.
[8] Booch, C., Object Orzented Analysis and Design wilh .-Ipplicatioas, 2nd ed., Ben-
jaminJCummings, Redwood City, California, 1993.
[9] Box, D ., Esse nt ial COM, Addson- Wesley, Reading, MA, 1997.
[IO] Comer, D.E., and Stevens. D.L., Intemet working with TCP/IP C'ol I: Principles,
Protocols. and Architectures, 2nd ed., Prentice Hall, Englewood Cliffs, NJ, 1992.
[I l] Corner. D.E.. and Stevens, D.L., Inter-nelworking with TCP/IP Vol III: Client-
Server Programming and rlpplications, 2nd ed.. Prentice Hall, Englewood Cliffs.
NJ, 1992.
(121 Coulouris, G., Dollirnore. J.. and Kindberg T.. Distributed Systerns - Concepts
and Design, 2nd ed., Addison-Wesley, Reading, MA. 1996.
[13] Custer, H.. Inside Windows .VT, Microsoft Press. Redrnond. Washington. 1993.
[LI] Dorf. R.C., and Bishop, R.H.. Modern Control Syste ma. Addison-Wesley, Read-
ing, iL1.A. 1995.
[l5] Gokhale, .A., and Schmidt. D.C.. *Meamring and Optimizing CORBA Latency
and Scalability Over High-Speed Networks." IEEE Transaction on Cornputers.
Vol. 47. No. 4. pp. 391-413. hpril 1998.
[16] Gokhale, A.. and Schmidt. D.C.. -Techniques for Optimizing CORBA Middle-
ware for Dist ributed Ernbedded Systems.' Proceedings of lEEE LVFOCOM '99.
New York. Marcfi 1999.
[17] Goodheart. B., CLWX Curses Explained. Prentice Hall of Australia Pty Ltd..
1991.
[18] Halsall, F.. Data Cornrnunication~, Computer iVetu?orks and Open Sydems. 4th
ed., Addison-Wesley, Reading, MA, 1996.
[19] Hardwick. hl., Spooner, D.L.. Rando, T., and Morris, K.C.. "Sharing Manufac-
turing Information in Virtual Enterprises,* Communications of ACM, Vol. 39,
No. 2, pp. 46-54, February 1996.
[%O] Hordeski, M.F., Control Technology and Persona1 Compute rs - System Design
and Irnplementation, Van Nostrand Reinhold, New York, 1992.
pl] IONA Technologies PLC.. 8-10 Lr. Pembroke St.. Dublin '>? Ireland, Orbix Ad-
ministrator's Guide - Orbix 2, 1997.
[Z] IONA Technologies PLC., 8- 10 Lr. Pembroke St ., Dublin 2. Ireland. Orbix Pro-
grammer> Guide - Orbix 2, 1997.
12:3] ION..\ Technologies PLC.. à- 10 Lr. Pernbroke St.. Dublin 2. Ireland, 01.bir Pro-
grammer's Rejérence - Orbir ?, 1997.
[--LI Johnson, R.E.. *Frameworks = (Components + Patterns).' Communications of
..ICM. Vol. 40. No. 10, pp. 39-42. October 1997.
[-51 hIeyers, S.. Efectioe C++ CD - 85 SpeciJic Ways to Irnproce Your Progrcims und
Designs, Addison-Wesley. Reading, M A . December 1998.
[26] hIcKusick. hl.K., Bostic. K., Iiarels, U.J.. and Quarterman. J.S.. The Design
and Irnplententnt ion of the 4.4 BSD Ope rat ing Syste m. :Idclson-Wesley. Reading,
MA, 1996.
[-71 Microsoft Corp.. and Digital Equipment Corp.. The Component Objeci .\Iode1
Specification. Version 0.9, October 2-4. 199.5.
[-SI Object khagement Croup. The Comrnon Object Request Broker: .4 rchiteet ure
and Specijication (CORBA). Object Management Choup (OMG). Framingham,
MA., Revision 1.2, Draft 29, December 1993.
[29] Paolini, C.. Integration of Heterogeneous Robotic Apparat us Lrsing COR BA, Mas-
ter's Thesis, Dept. of Cornputer Science. San Diego State University. Fall 1998.
[30] Papadopoulos, C., and Parulkar, G., -Experimental Evaluation of SUNOS IPC and TCP/IP Protocol Implementat ion," IEEE/A CLCI Transactions on iVet work-
ing, Vol. 1, No. 2, pp. 199-216, April 1993.
[31] Precision MicroDynamics Inc., # M l 2 Frances Ave., Victoria. British Columbia.
V5Z Ml, GL~IC-SO~~-LIB Co-ordinated Motion Control Library User's Manual,
@V,Y Version LI, 1999.
[3%] Precision MicroDynarnics Inc., #3-512 Frances rive., Victoria, British Columbia,
V5Z lhl, L W I O - ~ A Use& Manual, PC ibfotion Control Interface Card, QNX
Vem'on 1.9, 1999.
[U] Pyarali, I., Harrison, T.H.. and Schmidt, D.C., *Design and Performance of an
Object-Oriented Framework for High Performance ELectronic Medical Imaging,'
CJSENIX Comp uting Systems, Vol. 9, Novernber/December 1996.
[34] QNX Software Systems Lttl., 175 Terence Matthews Crescent, Kanata, Ontario.
M M 1 W8, W.ATCObl C Compiler 6; Tools LTser's Guide, 1993.
[35] QNX Software Systems Ltd., 179 Terence Matthews Crescent. Kanata, Ontario.
K2bI 1 WY, QNS 4 Operating System - System Architecture. February 1995.
[36] QNX Software Systerns Ltd.. 175 Terence Matt hews Crescent, Kaiiata, On-
tario, K2SI 1 WY, -QNX Realtime OS - Performance Profile.* CVorld Wide Ckb.
h t t p : / / w v v . qnx. com/products/os/qnxrtos . html#Perf ormance. 1999.
[37] Rago. S.A., L~:VIX System V Xetwork Programming. Addison-Wesley. Reading,
M X , 199%
[38] Schmidt. D.C., Gokhale, A.. Harrison. T.H., and Pariilkar, C.. -.A High-
performance Endsystern Architecture for Real-time CORBA.* IEEE Comrnu-
nications !Cfaga:ine, Vol. 14, No.2. February 1997.
[39] Schmidt, D.C., and Cleeland, C., ihpplying Pattens to Develop Extensible ORB Middleware," IEEE Communications :Claga:ine. Vol. 37. No. 4. pp. 36-54. April
1999.
[-LOI Schmidt, D.C., *Developing Distributed Object Compiiting Applications wit h
CORBA," World Wide Web, h t t p : / / m u .CS .vustl .edu/ schmidt/, February
1999.
[41] Schmidt, D.C., "IPCSAP: An Object-Oriented Interface to Interprocess Corn-
municat ion Services," C++ Report, Vol. 4, November/December 1993.
[42] Schmidt, D.C.. Levine, D.L., and Mungee, S., *The Design and Performance of
Real-Tirne Object Request Brokers," Cornputer Communications, Vol. 21, pp.
294324, Apr. 1998.
[U] Schmidt, D.C., and Stephenson. P., TJsing Design Patterns to Evolve System
Software from I?NlX to Windows NT." C++ Report. MarchjApril 1995.
[44] Silvano, hl., and Schmidt, D.C.. Tonstructing Reliable Distrihuted Communi-
cation Systems wi th CORBA.' lEEE Communication Jl<iga:ine, Vol. 14, No. 2,
pp. 56-60, February 1997.
LL5] Stevens, W.R.. Advanced Progrurnrning in the Unir f?llL?ir~nmd, Adcison-
Wesley, Reading, MA. 199'1.
[46] Stevens, W.R., W1.Y .Vetwork Programming: Interprocess Communicntions, Vol.
2. 2nd ed., Prentice Hall, Englewood Cliffs, NJ. N98.
[4i] Timmerman, 1.iCI.. and %Ionfret. I.J., -CVindows NT as Real-Time OS." World
\Vide Web, http : //ww . realt ime-inf o. be/encyc/magazine. 1999.
(481 Tsai. .J.J.P., Bi, Y.. Yang, S.J.H.. and Smith., R.A.W.. Dishibuted Real- Time
Systems - Monitoring, ~'isuali-ation, Debugging. and ilnalysis, John Wiley
&Sons Inc.. 1996.
[49] Vinoski, S., "CORBA: Integrating Diverse Applications Within Distributed Het-
erogeneous Environment," IEEE Communication :Clagazine, Vol. 3.2, No. 2, pp.
46-55, February 1992.
[50] Williams, S., and Kindel, C., iThe Component Object blodel: A Technical
Overview," Dr. Dobb 's Jo.urnal, December 1994.
[SI] Yang, Z., and Duddy, K., 'CORBA: A Platform for Distributed Object Corn-
puting," .ACM Opemting System Revzew, Vol. 30, No. 2. pp. 4-31, April 1996.
[52] Younkin, G.W., Industn'al Servo Control System. Marcel Dekker, Inc. NY, 1996.
(53) Zhang, Y .Q., Real- Time iWdt i- Taskiag Control Syst ern for a Dextrous Robot
Hand, M.A.Sc Thesis, Simon Fraser University, April 1998.
![michaelbradleysblog.files.wordpress.com · Tinie Tempah - Written In The B.o.B - Airplanes ft. Hayley Williams of Paramore [OFFICIAL VIDEO] Atlantic Records Subscribe 5.8M SHOW MORE](https://img.pdfslide.us/doc/110x75/5f03ba9a7e708231d40a7b53/tinie-tempah-written-in-the-bob-airplanes-ft-hayley-williams-of-paramore.jpg)
