New Interface for Rapid Feedback Control on ABB-robots

New Interface for Rapid Feedback Control on ABB-robots
New Interface for Rapid Feedback
Control on ABB-robots
A Master Thesis in Sensor-Integrated Industrial Robot Control at
Linköping Institute of Technology, Department of Mechanical engineering,
Division of Production Systems
Rasmus Lundqvist
Tobias Söreling
LiTH-IKP-EX--05/2210--SE
Avdelning, Institution
Division, Department
Datum
Date
2005-02-08
Institutionen for konstruktions- och
produktionsteknik
581 83 LINKÖPING
Språk
Language
Svenska/Swedish
X Engelska/English
Rapporttyp
Report category
Licentiatavhandling
X Examensarbete
C-uppsats
D-uppsats
ISBN
ISRN LITH-IKP-EX--05/2210--SE
Serietitel och serienummer
Title of series, numbering
ISSN
Övrig rapport
____
URL för elektronisk version
http://www.ep.liu.se/exjobb/ikp/mtk/2005/2210/
Titel
Title
New Interface for Rapid Feedback Control on ABB-Robots
Författare
Author
Lundqvist, Rasmus
Söreling, Tobias
Sammanfattning
Abstract
Automation in manufacturing has come far by using industrial robots. However, industrial robots require
tremendous efforts in static calibration due to their lack of senses. Force and vision are the most useful
sensing capabilities for a robot system operating in an unknown or uncalibrated environment [4] and by
integrating sensors in real-time with industrial robot controllers, dynamic processes need far less calibration
which leads to reduced lead time. By using robot systems which are more dynamic and can perform complex
tasks with simple instructions, the production efficiency will rise and hence also the profit for companies
using them.
Although much research has been presented within the research community, current industrial robot systems
have very limited support for external sensor feedback, and the state-of-the-art robots today have generally
no feedback loop that can handle external force- or position controlled feedback. Where it exists, feedback at
the rate of 10 Hz is considered to be rare and is far from real-time control.
A new system where the feedback control can be possible within a real-time behavior, developed at Lund
Institute of Technology, has been implemented and deployed at Linköping Institute of Technology.
The new system for rapid feedback control is a highly complex system, possible to install in existing robot
cells, and enables real-time (250 Hz) sensor feedback to the robot controller. However, the system is not yet
fully developed, and a lot of issues need to be considered before it can reach the market in other than specific
applications.
The implementation and deployment of the new interface at LiTH shows that the potential for this system is
large, since it makes production with robots exceedingly flexible and dynamic, and the fact that the system
works with real- time feedback makes industrial robots more useful in tasks for manufacturing.
Nyckelord
Keyword
Robot, Robot control, IRB4400, Feedback controller, Real time, Sensor, Force feedback
Sammanfattning
Automation i produktionsindustrin har kommit långt genom att använda
industriella robotar. Trots det krävs det väldigt mycket arbete för kalibrering för
att uppnå önskvärt resultat, detta på grund av deras brist på återkoppling från
sensorer. Kraft och syn är de mest användbara sensorfunktionerna för ett
robotsystem som arbetar i en för den okänd eller okalibrerad miljö. Genom att
integrera realtidssensorer som tillämpar kraft och syn kan ledtiden minskas
drastiskt genom att de dynamiska processerna kräver mycket mindre kalibrering.
Genom att använda robotsystem som kan utföra mer dynamiska och komplexa
arbetsuppgifter med enkla instruktioner så kommer produktionseffektiviteten öka
och därmed också vinstmarginalen för de företagen som använder sig av de
metoderna.
Trots att mycket forskning har pågått och presenterats i forskningssammanhang
så har dagens industriella robotsystem väldigt dåligt stöd för externa sensorer,
generellt har state-of-the-art robotar inget stöd för återkopplingsloop som stödjer
kraft- eller positionsåterkoppling. Där det existerar så är det sällan möjligt att
återkoppla med 10 Hz och det är således långt ifrån realtidsstyrning.
Ett system, för snabb återkoppling med realtidsbeteende utvecklat av Lunds
Tekniska Högskola, har blivit implementerat och installerat vid Linköpings.
Det nya systemet för snabb återkoppling är ett komplext system som är möjligt
att installera i existerande robotstyrsystem och möjliggör realtidsåterkoppling
(250 Hz) av sensorer till robotstyrningen. Systemet är inte fullt utvecklat och det
finns en del begränsningar i hur systemet är uppbyggt i dagsläget. Det finns även
en del punkter som måste tas med i beräkningarna innan systemet kan nå
marknaden i annat än specifika applikationer.
Det faktum att systemet fungerar med realtidsåterkoppling ökar
användningsområdet hos industriella robotar dramatiskt, uppgifterna som
robotarna klara av kan vara mycket mer komplexa och det nya systemets
potential är stor, eftersom det möjliggör användningen av robotar i
tillverkningsuppgifter som inte vara möjliga tidigare.
i
Abstract
Automation in manufacturing has come far by using industrial robots. However,
industrial robots require tremendous efforts in static calibration due to their lack
of senses. Force and vision are the most useful sensing capabilities for a robot
system operating in an unknown or uncalibrated environment [4] and by
integrating sensors in real-time with industrial robot controllers, dynamic
processes need far less calibration which leads to reduced lead time. By using
robot systems which are more dynamic and can perform complex tasks with
simple instructions, the production efficiency will rise and hence also the profit
for companies using them.
Although much research has been presented within the research community,
current industrial robot systems have very limited support for external sensor
feedback, and the state-of-the-art robots today have generally no feedback loop
that can handle external force- or position controlled feedback. Where it exists,
feedback at the rate of 10 Hz is considered to be rare and is far from real-time
control.
A new system where the feedback control can be possible within a real-time
behavior, developed at Lund Institute of Technology, has been implemented and
deployed at Linköping Institute of Technology.
The new system for rapid feedback control is a highly complex system, possible
to install in existing robot cells, and enables real-time (250 Hz) sensor feedback
to the robot controller. However, the system is not yet fully developed, and a lot
of issues need to be considered before it can reach the market in other than
specific applications.
The implementation and deployment of the new interface at LiTH shows that the
potential for this system is large, since it makes production with robots
exceedingly flexible and dynamic, and the fact that the system works with realtime feedback makes industrial robots more useful in tasks for manufacturing.
iii
Acknowledgements
The work presented in this report has been carried out as a Master Thesis at IKP
during the autumn 2004. First of all, we want to thank our examiner and
supervisor; Gilbert Ossbahr.
We would also like to thank Henrik Kihlman, who has been a great resource as
supervisor in the project although he has been in Australia most of the time.
Thanks to all the guys in Lund: Klas Nilsson, Mathias Haage, Tomas Olsson,
Anders Blomdell and Anders Robertsson, that helped us through some tough
times. We are particularly grateful to Mathias Haage and Tomas Olsson that have
been very helpful in stressful times.
Thanks to Ulf Bengtsson and the guys at the mechanical workshop at IKP for
help with making and modifying the tools needed throughout the project.
We would also like to thank the staff at Production system, IKP, for their friendly
atmosphere.
Rasmus Lundqvist
Tobias Söreling
v
Notation
ABB Robotics AB – Allmänna Svenska Elektriska Aktiebolaget Brown Boveri
Robotics Aktiebolag
ADAM – Advantech Data Aquisition Modules
ADFAST – Automation for Drilling, Fastening, Assembly, Systems Integration,
and Tooling
AUTOFETT – Affordable Flexible System for Off-line Automated Fettling and
Finishing
CVS – Concurrent Versions System
DHCP – Dynamic Host Configuration Protocol
DNS – Dynamic Name Server
DOF – Degrees Of Freedom
ESD – Electrostatic discharge
ExtRAPID – Extended RAPID, robot programming language developed at LTH
F/T – Force / Torque
FAT32 – File Allocation Table, 32 bit.
FlexAA – Flexible and Accurate Automation
FTP – File Transfer Protocol
G4 PPC – G4 Power Performance Card
GUI – Graphical User Interface
I/O – Input / Output
IKP – Institutionen för Konstruktion och Produktion (Department of Mechanical
Engineering)
IRB – Industrial Robot
ISA - Industry Standard Architecture
LiTH – Linköpings Tekniska Högskola (Linköping Institute of Technology)
LTH – Lunds Tekniska Högskola (Lund Institute of Technology)
MAC - Machine Access code
NTFS - New Technology File System
PCI – Periferal Component Interconnect
PMC – PCI Mezzanine Card
PrPMC – Processor PMC
RPM – Red Hat Package Manager
RS232 – Recommended Standard 232
S4Cplus – ABB Industrial Robot controller
SLIP – Serial Line Internet Protocol
SSH – Secure Shell Host
TCP – Tool Centre Point
TCP/IP – Transmission Control Protocol / Internet Protocol
TPU – Teach Pendant Unit
UDP – User Datagram Protocol
vii
Contents
Chapter 1
Introduction ..................................................................................1
1.1
Background............................................................................................1
1.2
Purpose ..................................................................................................2
1.3
Method...................................................................................................3
1.4
Aim ........................................................................................................3
1.5
Outline ...................................................................................................4
Chapter 2
Robot technology ..........................................................................5
2.1
Industrial Robots ...................................................................................7
2.2
Robot programming...............................................................................7
2.3
Robot Controllers ..................................................................................9
Chapter 3
System Description .....................................................................11
3.1
System overview .................................................................................11
3.2
Robot and Controller ...........................................................................12
3.2.1
IRB4400[12] ....................................................................................12
3.2.2
S4Cplus Controller[11] ....................................................................13
3.2.3
DSQC332[11] ..................................................................................16
3.2.4
RobotWare [10]................................................................................17
3.3
Hardware .............................................................................................22
3.3.1
G4 PowerPC.....................................................................................22
3.3.2
PMC-PCI..........................................................................................23
3.3.3
Flash Disc.........................................................................................23
3.3.4
MasterPC..........................................................................................24
3.3.5
Advantech PCI-1711........................................................................24
3.3.6
Sensor...............................................................................................25
3.3.7
Tools.................................................................................................26
3.4
Software...............................................................................................27
3.4.1
SensorControl...................................................................................28
3.4.2
ExtCtrl..............................................................................................29
3.4.3
Opcom..............................................................................................32
3.4.4
G4.....................................................................................................35
3.4.5
Modification of ABB:s start up script..............................................36
3.5
Network / Communication ..................................................................37
3.5.1
TCP/IP..............................................................................................38
3.5.2
SLIP/RS232 .....................................................................................38
3.5.3
RAP/RPC .........................................................................................38
3.5.4
I/O (Advantech) ...............................................................................39
3.5.5
PCI Backplane..................................................................................39
3.5.6
Inside S4Cplus controller.................................................................40
ix
Chapter 4
ExtRAPID....................................................................................41
4.1
Why ExtRAPID? .................................................................................41
4.2
Basic idea.............................................................................................41
4.3
Syntax ..................................................................................................41
4.4
Sensor scope ........................................................................................42
4.5
Force scope..........................................................................................43
4.6
Build phase ..........................................................................................43
4.7
Process phase.......................................................................................44
4.8
Retract phase .......................................................................................44
4.9
Restrictions ..........................................................................................45
4.10
Stepwise force function .......................................................................46
Chapter 5
Case study....................................................................................49
5.1
Hardware installation...........................................................................49
5.2
Operating system .................................................................................52
5.2.1
Linux ................................................................................................54
5.2.2
DHCP server ....................................................................................54
5.2.3
Java...................................................................................................56
5.2.4
Installing and Use of Comedi...........................................................57
5.2.5
Adapting Advantech to fit LTH’s software [9]................................57
5.3
Software installation ............................................................................58
5.4
Control algorithms...............................................................................60
5.5
Configuration methodology.................................................................61
5.6
Performance.........................................................................................64
5.7
Problems ..............................................................................................66
Chapter 6
Conclusion ...................................................................................67
Chapter 7
Bibliography................................................................................71
Appendix A
Appendix B
Appendix C
Appendix D
Appendix E
Appendix F
Appendix G
ExtRAPID An Example .............................................................73
Running an ExtRAPID program. .............................................77
ATI F/T Sensor ...........................................................................79
G4 PowerPC PrPMC800-1261 ..................................................81
Advantech PCI-1711...................................................................85
dhcpd.conf ...................................................................................87
Stork .........................................................................................89
x
List of figures
Fig. 1 The participating parties in FlexAA.............................................................2
Fig. 2 Robots in Sweden [27] .................................................................................5
Fig. 3 The future of robotics 1981 [28]. .................................................................6
Fig. 4 Delmia environment .....................................................................................8
Fig. 5 ABB Robot and Industrial Robot Controller................................................9
Fig. 6 Overview of the new interface ...................................................................11
Fig. 7 IRB 4400 [12].............................................................................................13
Fig. 8 Inside the S4Cplus......................................................................................13
Fig. 9 Schematic picture of DSQC332 [12]..........................................................16
Fig. 10 Output terminal on DSQC332 [12] ..........................................................16
Fig. 11 Input terminal on DSQC332 [12].............................................................17
Fig. 12 G4 PowerPC.............................................................................................22
Fig. 13 PMC -PCI.................................................................................................23
Fig. 14 PMC-PCI connected with G4 PowerPC...................................................23
Fig. 15 Flash disc..................................................................................................24
Fig. 16 Advantech PCI-1711 ................................................................................24
Fig. 17 ATI F/T Sensor with sensor-board...........................................................25
Fig. 18 - Tool with spring and bearing. ................................................................26
Fig. 19 New tool with ball end .............................................................................26
Fig. 20 - Software architecture with physical layers ............................................27
Fig. 21 Sensor control, main window...................................................................28
Fig. 22 Sensor control, connect window ..............................................................29
Fig. 23 Flowchart of ExtHandler (left) and ExtReciever (right) ..........................30
Fig. 24 - RapHandler flowchart ............................................................................31
Fig. 25 Opcom, start window ...............................................................................32
Fig. 26 Opcom, all parameters..............................................................................33
Fig. 27 The control loop between the S4Cplus and G4. .......................................36
Fig. 28 The systems different connection paths ...................................................37
Fig. 29 RS232 Cable.............................................................................................38
xi
Fig. 30 Schematic picture of Advantech coupling................................................39
Fig. 31 Advantech coupling at DSQC 332 ...........................................................39
Fig. 32 Communication protocols used inside the controller unit [13] ................40
Fig. 33 Flowchart of hardware installation...........................................................49
Fig. 34 Inside S4Cplus computer unit ..................................................................50
Fig. 35 Close up of sensor and tool ......................................................................51
Fig. 36 Complete demo setup ...............................................................................52
Fig. 37 Flowchart of Operating system installation..............................................52
Fig. 38 Partition table, MasterPC .........................................................................53
Fig. 39 Flowchart of software installation............................................................59
Fig. 41 Configuration methodology flowchart .....................................................61
Fig. 42 Test run with constant force 50 N, x axis is seconds, y axis is Newton...64
Fig. 43 Sensor delay .............................................................................................65
Fig. 44 Adaptive movements on an unknown shape. ...........................................65
Fig. 45 Extreme accuracy with sensor feedback ..................................................68
Fig. 46 Following objects and grinding with standard robots ..............................69
xii
Chapter 1
Chapter 1
Introduction
Introduction
utomation in manufacturing is to a large extent dependent on the use of
robots. By using robot systems, which are more flexible and can perform
complex tasks with simple instructions, the production efficiency is
improved and hence also the profit for companies that uses them [22].
A trend seen in industrialized countries such as Sweden is that companies move
their production to low-wage countries. Increased globalisation makes it
necessary for Swedish industries to enhance their ability to develop and
manufacture products competitively in order to counteract this trend. One of the
main goals of the ProViking venture is to support research in this field [1].
Extended use of automation is one important enabling technology to achieve this
and retain production in Sweden.
Automation in manufacturing today has come far by using industrial robots.
However, industrial robots require tremendous efforts in calibration, due to the
lack of feedback from external sensors. Force and vision are the most useful
sensing capabilities for a robot system operating in an unknown or uncalibrated
environment [4] and by integrating sensors in real-time with industrial robot
controllers, dynamic processes are possible, which needs far less calibration and
leads to reduced lead time.
This project is focusing on implementing an interface between sensors and ABB
robots as a way to induce the robot capability and flexibility in real-time
automation processes.
1.1 Background
Industrial robots have existed in its current form for decades now, and little has
changed in the robots constructions and controllers. Although much research has
been presented within the research community, current industrial robot systems
have very limited support for external sensor feedback.
This Master Thesis is a part of a larger research project called FlexAA, financed
by Proviking [1], with the aim to make automation in aircraft manufacturing
more flexible and robots more dynamic and accurate. The FlexAA project is in
turn using results from earlier research projects conducted at the Linköping
Institute of Technology (LiTH), department of Production Systems and at Lund
Institute of Technology (LTH).
One project that the Department of Mechanical Engineering (IKP) at LiTH earlier
has focused on is the ADFAST (Automation for Drilling, Fastening, Assembly,
1
New Interface for Rapid Feedback on ABB-robots
Systems Integration, and Tooling) project. An aim in this project was to guide the
tool on an Industrial ABB Robot to extreme position accuracy [16].
Another earlier project is the AUTOFETT [1] project, where a new feedback
interface for ABB robots was developed at LTH. The feedback interface is
designed to use simple instructions to the robots highly complex control system
and allows online dynamic recalibration of the robot using third party
communication to be installed in existing robot cells. The work on the
development of this feedback interface for external control was supported by the
EU 5th Framework Growth Project Affordable, flexible system for offline
automated fettling and finishing, AUTOFETT.
The FlexAA project is a joint research project with the two university partners
LiTH and LTH and several industrial partners according to Fig. 1.
SAAB
Aerostructures
Linköping
Institute of
Technology
(LiTH)
ABB Automation
ETP
Lund
Institute of
Technology
(LTH)
Meeq
Sandvik
Fig. 1 The participating parties in FlexAA
1.2 Purpose
The problem with the flexibility of currently available robots is that the feedback
from external sensors is slow. The state-of-the-art robots today generally have no
feedback loop that can handle external force- or position controlled feedback, and
where it exists, feedback at the rate of 10 Hz is considered to be rare, and this is
far from real-time control. Force control has existed within the research
community for 10-20 years, but has not been presented in industrial robot
controllers. In this project, a system developed at LTH within the AUTOFETT
2
Chapter 1
Introduction
project, will be implemented, where the feedback control can be possible within a
real-time behaviour, 4 ms / 250 Hz.
The purpose of implementing the new interface for ABB robots at LiTH is to
look into the amount of system dependent information that has to be changed
during the implementation in order to get the interface to work properly. Also,
after implementing the system at LiTH, it was to be tested in order to see what
possibilities the new interface may provide to improve automation and flexibility,
primarily in aircraft production.
1.3 Method
The method used in this project can be summarised in five parts in chronological
order:
A) Perform literature studies of robotics and recent research.
B) Practise robot programming and evaluate the physical limitations of the
robot.
C) Study the hardware needed for the new interface and install it
D) Implement the new software for the system and configure it.
E) Use the ExtRAPID language to evaluate the system and its capabilities.
1.4 Aim
The aim for this Master Thesis is to successfully implement the system for rapid
feedback developed by LTH, in the robot system at IKP, LiTH. Furthermore,
both the system and the process for implementing it should be thoroughly
evaluated and documented.
In the specification of the project, four main tasks are emphasised;
1. Cover the implementation of the new interface.
2. Map what changes are needed in software and hardware to get the same
behaviour as at LTH, as a result of this a methodology for adapting the
interface will be developed.
3. Test and evaluate the system.
4. Implement the ExtRAPID language, developed at LTH, and enable one or
two adaptive subprograms to control the robot in adaptive mode from an
external computer.
3
New Interface for Rapid Feedback on ABB-robots
1.5 Outline
Chapter 2 – Robot technology
This chapter gives a introduction to robot technology by describing what defines
a robot, how its world usually is defined and how it is programmed. This leads us
to state-of-the-art robots and the ABB robot used in this project. This chapter is
important for the understanding of how the robots of today work and thereby how
this new interface affects the subject.
Chapter 3 – System description
This chapter starts by describing the system from a large perspective, for fast
understanding of the general idea of the system. Then the different parts of the
system are described in depth.
Chapter 4 – ExtRAPID
This chapter describes the language ExtRAPID from a user perspective.
Chapter 5 – Case study
This chapter describes the controller and the changes in the system that has been
made to make the system run at LiTH. Furthermore, the methodology for
implementing the system at a new location will be described, and the conducted
measurements and tests will be presented.
Chapter 6– Conclusion
The results of the project are presented in consideration of this projects purpose
and aim.
4
Chapter 2
Chapter 2
Robot technology
Robot technology
The word Robot comes from the Czechoslovakian word robota which means
heavy, monotonous or forced work. It was the writer Karel Capek who in 1920
wrote a play (RUR, Rossum’s Universal Robot) about machines that was created
in a human figure, who gave the word its present meaning. The word was
originally referring to the two or three days per week when the farmers and
peasants living in the feudal society of that time, had to leave their own farm to
go work on the noblemen’s land without payment. Even though the word ‘robot’
has a negative heritage, it is well known fact today that robots can take over the
work that is considered dull, heavy or hazardous and create new qualified
employment as robot programmers, engineers etc. It was to replace humans in
heavy and dangerous work tasks the first industrial robots was developed. The
first commercial robot was in use at Ford Motor Company in 1961, where it
served a pressure casting machine [24].
Since then robotics has extended in use rapidly, and nowadays most of the big
production companies use robots for manufacturing extensively. The number of
operational robots in use in Sweden now exceeds 7000, and keeps increasing.
Fig. 2 Robots in Sweden [27]
Even if robots are used extensively for production, the development of new
functions for robots has not gone as fast as the industry thought. In the early 80´s
Fig. 3 was published in the largest technological newspaper in Sweden, Ny
Teknik, and it shows what generally was thought about future development in
robotics.
5
New Interface for Rapid Feedback on ABB-robots
Fig. 3 The future of robotics 1981 [28].
The research has come far in some areas (i.e. Vision), but the use in industrial
controllers is still rare, and the prediction Ny Teknik made is still far from reality.
As for this project we are still at square one, in implementing sensitivity and
adaptivity in real time control.
Definition of a robot
According to Webster [23] a robot is:
"An automatic device that performs functions normally ascribed to
humans or a machine in the form of a human."
Inspiring indeed, but since it is difficult to define exactly what “functions
normally described to humans” are, a more correct definition would be the one
according to the Robot Institute of America (1979):
"A reprogrammable, multifunctional manipulator designed to move
material, parts, tools, or specialized devices through various
programmed motions for the performance of a variety of tasks".
This definition, however, describes most machines that are automatic in any
form, and it is therefore necessary to divide robotics in different subgroups,
depending on what they are used for. Some subgroups are:
• Autonomous research robots (like Space Exploration robots)
• Service robots (like autonomous vacuum-cleaners)
6
Chapter 2
Robot technology
• Military robots
• Industrial robots (Robot systems for manufacturing)
This project focuses only on industrial robots, so the other types of robots will
not be discussed any further in this report.
2.1 Industrial Robots
An industrial robot is officially defined by ISO as an automatically controlled,
reprogrammable, multipurpose manipulator programmable in three or more axes
[26]. The field of industrial robotics may be more practically defined as the study,
design and use of robot systems for manufacturing (a top-level definition relying
on the prior definition of robot) [24].
Typical applications of industrial robots include welding, painting, ironing,
assembly, pick and place, palletizing, product inspection, and testing, all
accomplished with high endurance, speed, and precision. Manufacturers of
industrial robots include:
• Intelligent Actuator
• Adept
• Epson Robots
• Yaskawa-Motoman
• ABB
• EPSON-SEIKO
• igm Robotersysteme
• KUKA
• Kawasaki
• FANUC Robotics
2.2 Robot programming
The setup or programming of motions and sequences for an industrial robot is
typically taught by linking the robot controller via communication cable to the
serial port of a computer. The computer is installed with corresponding interface
software. The use of a computer greatly simplifies the programming process.
Robots can also be taught via teaching pendant, a handheld control and
programming unit. The teaching pendant or PC is usually disconnected after
7
New Interface for Rapid Feedback on ABB-robots
programming and the robot then runs on the program that has been installed in its
controller. In addition, machine operators often use "HMI" human-machineinterface devices, typically touch screen units, which serve as the operator control
panel.
Offline Programming
The programming of a robot can also be done Offline, which means that the
programming takes place without contact with the robot. Since the programming
takes place on a computer at another place, the result is that the robot does not
have to be shut off during programming, but can continue its work without time
loss.
The programming is made in advanced software programs where you often can
simulate the robots movements, to make sure it does not crash into anything and
that it really performs the tasks one specifies. Many programs also provides the
possibility to simulate several different robots at the same time, and in some
cases whole factories can be programmed and simulated, combining both manual
and automatic tasks. Examples of programs is ABB Robot Studio, Delmia,
RobCAD, Robot3D, etc.
Fig. 4 Delmia environment
8
Chapter 2
Robot technology
RAPID
The programming language for ABB robots is called RAPID. It was developed to
address the need for increased flexibility and more power demanded by the
industry. Rapid was introduced in the early nineties and was a huge step for ABB
Up to this time ABB had offered customers a relatively simple programming
language this was designed for ease of use and quick results in mind, and big
customers soon discovered its limitations.
A RAPID program consists of instructions and data that controls a robot and its
equipment in a desirable way. An instruction is described according to this
structure [17]:
Instruction
Argument
Mutually excluding arguments
2.3 Robot Controllers
To manoeuvre a robot, there is of course more needed than the robot arm that you
see when you look at a robot. Normally, a robot comes with a special controller
that interprets robot programs, calculates robot movements, and controls the
robots electro-mechanical motors or actuators.
Fig. 5 ABB Robot and Industrial Robot Controller
These controllers are highly advanced industrial computers that require special
design with security, EMC and stability issues in mind.
9
Chapter 3
Chapter 3
System Description
System Description
In this chapter the new system for rapid feedback will be described, ranging from
the hardware to the software environment which is necessary for running the
system. The chapter starts with a short introduction to the whole system and its
different parts. After that the different parts will be described thoroughly to get a
greater understanding of the system.
3.1 System overview
The new interface is a complex system with many different parts, hardware as
well as software.
Fig. 6 Overview of the new interface
The system is built upon:
• External computer – Called Master PC
• Robot – IRB 4400
• Robot Controller – S4Cplus
• Power PC card – G4 processor with memory, PMC Interface
• PMC-PCI card – Interface between the Power PC card and the PCI
Backplane
• Flash Disc – Replaces the Robot controller’s original Ram disc
11
New Interface for Rapid Feedback on ABB-robots
• Advantech card – Inside the MasterPC for basic IO coupling
• Sensor – ATI FT Sensor and corresponding computer interface
• Network environment – Configured from the Master PC
• Software environment on the Master PC – Making it able to execute and
supervise ExtRAPID programs
• Operative system on the Robot controller – BaseWare and its different
parts
• Sensor PC – Used to capture and pass on sensor information, this could be
done on Master PC or inside controller, so this computer is in some cases
redundant.
There are closer descriptions of the parts and its connections in the forthcoming
subchapters.
3.2 Robot and Controller
The robot cell at LiTH is built around an IRB4400 and an S4Cplus controller unit
from ABB. The different units and their characteristics as well as software
environment are described below.
3.2.1 IRB4400[12]
The IRB 4400 is a 6-axis industrial robot, from the beginning brought forth for
automotive industry, to do spot welding and pick-and-place operations and the
robots design is optimized for these tasks. The robot has built-in process ware, an
open structure that is specially adapted for flexible use, and can communicate
extensively with external systems.
The IRB 4400 comes in several different versions, with handling capacities of up
to 60 kg, a maximum reach of 2.5 m, floor or shelf-mounted manipulators as well
as manipulators for harsh environments. The IRB 4400 used at LiTH is a 4400/60
which means that it can handle a weight of 60 kg in specified limitations.
The robot is equipped with the operating system BaseWare OS. BaseWare OS
controls every aspect of the robot, like motion control, development and
execution of application programs communication etc.
For additional functionality, the robot can be equipped with optional software for
application support - for example gluing and arc welding, communication
features - network communication - and advanced functions such as multitasking,
sensor control etc.
12
Chapter 3
System Description
Fig. 7 IRB 4400 [12]
3.2.2 S4Cplus Controller[11]
The robot controller unit is built around a core of three different computer
systems:
• Main computer Board
• Axis Computer Board
• I/O Computer Board
The computers are the data processing centre of the robot. They possess all the
functions required to create, execute and store a robot program. They also contain
functions for coordinating and regulating the axis movements. On top of these, it
is possible to add up to five Optional Boards for additional functionality.
Fig. 8 Inside the S4Cplus
13
New Interface for Rapid Feedback on ABB-robots
Main computer board
• The Main Computer Board contains the main computer of the robot and
controls the entire robot.
Axis computer board
• Regulates the velocity and torque of up to seven axes. Set points for
positions are sent from the main computer to the axis computer. The axis
computer receives position set values from the main computer and current
position from the serial measurement board. The axis computer uses this
data in regulating algorithms and transmits the torque set value and the
position values to the drive system.
I/O computer board
• This is the link between the main computer and the process equipment, e.g.
I/O units.
There are some optional boards that can be used inside the controller unit to
extend the functionality of the system. Below are some of them and in short
words described what they do:
• Extra axis computer(s) -Needed for control of additional external axes.
• Extra I/O computer - Needed for extra I/O channels (CAN buses,
Ethernet).
• Field bus boards - E.g. Profibus DP, Interbus-S, ContolNet.
In addition to the computer system the controller unit consists of Servo system,
I/O System, Safety system and External Axes. The system at LiTH uses no
External Axes, so the functions of the External Axes are not described any closer
in this report.
Servo System
The servo system is a complex system comprising several different interacting
units and system parts – both hardware and software. The servo function
comprises:
• Digital regulation of the position, velocity and motor current of the robot
axes.
• Synchronous AC operation of the robot motors.
14
Chapter 3
System Description
Safety System
The robot’s safety system is based on a two-channel safety circuit that is
continuously monitored. If an error is detected, the power supply to the motors is
switched off and the brakes engage. To return the robot to MOTORS ON mode,
the two identical chains of switches must be closed. As long as these two chains
differ, the robot will remain in the MOTORS OFF mode.
The function of the safety circuit can be described as a combination of
mechanical switches and computer system controlling.
The emergency stop buttons on the operator’s panel, Teach Pendant Unit (TPU)
and external emergency stop buttons are included in the two-channel chain of
operation. A safeguarded stop, AUTO STOP, which is active in the AUTO
operating mode, can be connected by the user. In any of the MANUAL modes,
the enabling device on the TPU overrides the AUTO STOP.
The safeguarded stop GENERAL STOP is active in all operating modes and is
connected by the user. The aim of these safeguarded stop functions is to make the
area around the manipulator safe while still being able to access it for
maintenance and programming. If any of the dual switches in the safety circuit
are opened, the circuit breaks, the motor contactors drop out, and the robot is
stopped by the brakes. If the safety circuit breaks, an interrupt call is sent directly
from the panel unit to the computer system to ensure that the cause of the
interrupt is indicated.
When the robot is stopped by a limit switch, it can be moved from this position
by jogging it with the joystick while pressing the MOTORS ON button. The
MOTORS ON button is monitored and may be depressed for a maximum of 30
seconds.
The principle task of the safety circuit is to ensure that the robot goes into
MOTORS OFF mode as soon as any part of the chain is opened. The computer
system itself controls the last switch. In AUTO mode, you can switch the robot
back on by pressing the MOTORS ON button on the operator’s panel. If the
circuit is OK, the computer system will close the Solid state switch to complete
the circuit. When switching to MANUAL, the mode changes to MOTORS OFF
and the computer system opens the Solid state switch. In any of the MANUAL
modes, you can start operating again by pressing the enabling device on the
Teach Pendant Unit. If the circuit is OK, the computer system will close the Solid
state switch to complete the circuit.
15
New Interface for Rapid Feedback on ABB-robots
3.2.3 DSQC332[11]
The DSQC332 is an IO unit with 16 outputs and 16 inputs. In Fig. 9 you can see
a schematic picture of the unit.
Fig. 9 Schematic picture of DSQC332 [12]
In figure Fig. 10 and Fig. 11 it is possible to see the input and output terminals on
the DSQC332 unit. The output terminal is useful because of the fact that it
supplies different feeds to the different outputs. Corresponding a and b pins get
the same voltage level when relay is active (set to 1). This is very useful when
using external equipments that need different voltage levels.
Fig. 10 Output terminal on DSQC332 [12]
16
Chapter 3
System Description
What can bee seen in Fig. 11 is that there are unused pins in booth the X3 part as
well as the X4 part. The only thing that can be changed in the input part is the
zero reference.
Fig. 11 Input terminal on DSQC332 [12]
3.2.4 RobotWare [10]
RobotWare is a family of software products from ABB Automation Technology
Product AB, Robotics. It is designed to make increase productivity and lower the
costs of owning and operating a robot.
ABB Automation Technology Product AB, Robotics has invested many manyears into the development of RobotWare and it represents knowledge and
experience based on several thousand robot installations.
Within the RobotWare family there are three classes of products:
BaseWare OS - This is the operating system of the robot and constitutes the
kernel of the RobotWare family. BaseWare OS provides all the necessary
features for fundamental robot programming and operation. It is an inherent part
of the robot but can be provided separately for upgrading purposes.
BaseWare Options - These products are options that run on top of BaseWare OS.
BaseWare OS contains functionality for robot users that need additional
functionality, for example run multitasking, transfer information from file to
robot, communicate with a PC, perform advanced motion tasks etc.
17
New Interface for Rapid Feedback on ABB-robots
ProcessWare - ProcessWare products are designed for specific process
applications like welding, gluing and painting. ProcessWare is primarily designed
to improve the process result and to simplify installation and programming of
applications. These products also run on top of BaseWare OS.
BaseWare Options installed at LiTH.
Some Options are installed to make the work easier and some of the Options are
necessary for the system to work. The Options installed on the S4Cplus unit at
LiTH are:
• [531] Advanced Motion
• [532] Multitasking
• [534] FactoryWare Interface
• [535] RAP Communication
• [543] Ethernet Services
The numbers in the square brackets ([xxx]) are the ABB specification numbers
for the Options. In the following sub chapter it is described in more detail what
the different BaseWare Options do.
What the different BaseWare Options do [10]?
[531] Advanced Motion
Contains functions that offer the following possibilities:
• Resetting the work area for an axis.
• Independent movements.
• Contour tracking.
• Coordinated motion with external manipulators.
[532] Multitasking
Up to 10 programs (tasks) can be executed in parallel with the normal robot
program.
• These additional tasks start automatically at power on and will continue
until the robot is powered off, i.e. even when the main process has been
stopped and in manual mode.
• They are programmed using standard RAPID instructions, except for
motion instructions.
18
Chapter 3
System Description
• They can be programmed to carry out various activities in manual or
automatic mode, and depending on whether or not the main process is
running.
• Communication between tasks is carried out via I/O or global data.
• Priorities can be set between the processes.
Below are some examples of applications that can be used with multitasking
• The robot is continuously monitoring certain signals even when the robot
program has stopped, thus taking over the job traditionally allocated to a
PLC.
• An operator dialogue is required at the same time as the robot is doing, for
example, welding. By putting this operator dialogue into a background
task, the operator can specify input data for the next work cycle without
having to stop the robot.
• The robot is controlling a piece of external equipment in parallel with the
normal program execution.
You might think that there would be problems with the performance when using
multitasking, but when various processes are programmed in a correct way, no
performance problems will normally occur. Below are some important items
which are important to keep in mind when programming.
• When priorities for various processes are correctly set, normal program
execution of the robot will not be affected.
• Because monitoring is implemented via interrupts (instead of checking
conditions at regular intervals), processor time is required only when
something actually happens.
• All input and output signals are accessible for each process.
Multitasking is primary intended for less demanding tasks. The normal response
time is about 5 ms, but in the worst cases, e.g. when the processor is computing
new movements, it can be up to 120 ms. The available program memory can be
divided up arbitrarily between the processes. However, each process in addition
to the main process will reduce the total memory,
[534] FactoryWare Interface
This option enables the robot system to communicate with a PC. FactoryWare
Interface serves as a run-time license for WebWare, i.e. the PC does not require
any license protection when executing a WebWare based application.
19
New Interface for Rapid Feedback on ABB-robots
Factory Ware Interface includes the Robot Application Protocol (RAP). The
Robot Application Protocol is used for computer communication. The following
functions are supported:
• Start and stop program execution
• Transfer programs to/from the robot
• Transfer system parameters to/from the robot
• Transfer files to/from the robot
• Read the robot status
• Read and write data
• Read and write output signals
• Read input signals
• Read error messages
• Change robot mode
• Read logs
RAP communication is available both for serial links and Ethernet connection.
Examples of applications:
• Production is controlled from a superior computer. Information about the
robot status is displayed by the computer. Program execution is started and
stopped from the computer, etc.
• Transferring programs and parameters between the robot and a PC. When
many different programs are used in the robot, the computer helps in
keeping track of them and by doing back-ups.
[535] RAP Communication
This option is required for all communication with a superior computer, where
none of the WebWare products are used. It includes the same functionality
described for the option Factory Ware Interface.
It also works for the WebWare products. There is no difference from the
FactoryWare Interface (except that the price is higher). Both FactoryWare
Interface and RAP Communication can be installed simultaneously.
[543] Ethernet Services
Ethernet Services can appear in two different shapes. Either for use with FTP or
with NFS as protocol when mounting remote discs.
20
Chapter 3
System Description
The aspect of authorization differs between NFS and FTP, which is the only
considerable difference.
Examples of applications where Ethernet Services could be used:
• All programs for the robot are stored in the PC. When a new part is to be
produced, i.e. a new program is to be loaded; the program can be read
directly from the hard disk of the PC. This is done by a manual command
from the teach pendant or an instruction in the program. If the option RAP
Communication or FactoryWare Interface is used, it can also be done by a
command from the PC (without using the ram disc as intermediate
storage).
• Several robots are connected to a PC via Ethernet. The control program
and the user programs for all the robots are stored on the PC. A software
update or a program backup can easily be executed from the PC.
21
New Interface for Rapid Feedback on ABB-robots
3.3 Hardware
There are several pieces that have to be installed to make the system work, and
the hardware recipe for successful real time robot control is as follows:
1 G4 PowerPC
1 PMC-PCI Card
1 Flash Disc
1 PC with 2 com ports and a Advantech 1711 Card
1 Sensor of choice
1 set of tools for testing the system
The different parts are further described below.
3.3.1 G4 PowerPC
The G4 PowerPC is a complete computer on a single board (except the hard
drive), with a 450 MHz Motorola processor, and 128 Mb RAM (available with
other memory sizes). The PowerPC is a RISC architecture based on the IBM
POWER architecture, and is very common in embedded systems. The
abbreviation PC in PowerPC stands for “Performance Card”.
Fig. 12 G4 PowerPC
The connection from the PowerPC is a PMC bus. PMC stands for PCI Mezzanine
Card, and is primarily used as an extension bus for industrial CPU cards, such as
a PowerPC. The PMC bus is similar to the PCI bus, apart from the physical form,
and belongs to the IEEE Common Mezzanine Card Standard (CMC) [20].
There are two other I/O connections to the G4, apart from the PMC, and that is an
Ethernet 10/100 Mbit/s connection and possibility to a serial interface.
22
Chapter 3
System Description
3.3.2 PMC-PCI
This is the link between the PowerPC and the S4Cplus. The connection in the
S4Cplus is PCI and the connection on the PowerPC is PMC, therefore it is
necessary with a PMC-PCI Card to interconnect them. The PMC-PCI is a PCI
carrier board designed to provide the use of a PMC board (like the G4 PowerPC)
in a PCI environment (like the S4Cplus) [21].
The card used is an ADC-PMC, manufactured by Alpha Data, which is based on
the 21154 64-bit 66MHz PCI-PCI bridge manufactured by Intel. This device
supports 64 or 32 bit primary PCI and 64 or 32-bit secondary PCI.
Fig. 13 PMC -PCI
The PMC-PCI used in the system is altered from the standard card. The G4
PowerPC should have shared memory with the S4Cplus, and it should be
accessed over the PCI bus. In the PCI bus, however, many different memories
and functions can be accessed that the G4 should not be able to change. Therefore
the channels that are restricted are shut off in the hardware of the PMC-PCI-Card.
Fig. 14 PMC-PCI connected with G4 PowerPC
3.3.3 Flash Disc
In the robot control system (S4Cplus), not only a G4 PowerPC with PMC Card
is needed, but also a new Flash Disc.
23
New Interface for Rapid Feedback on ABB-robots
Fig. 15 Flash disc
The original hard drive in the control system is too small for our needs, therefore
it is replaced with a new, 2 Gb, Flash Disc. The Flash disc has to be formatted to
be recognized by ABB’s memory interface
3.3.4 MasterPC
The recommendation for MasterPC is a quite fast processor (>1GHz), about 256
Mb Ram and a 40 Gb Hard Drive. Other than that, the MasterPC needs to be
equipped with some extra features:
2 Ethernet 100Mb network cards
2 Com ports
1 Advantech 1711 Card with ADAM wire terminal
3.3.5 Advantech PCI-1711
The Advantech PCI-1711 is a powerful and low-cost multifunction card for the
PCI bus which is needed for the communication between the S4Cplus and the
MasterPC (see chapter 3.5). The card provides multiple measurements and
control functions, and is used as an interface for I/O signals.
Fig. 16 Advantech PCI-1711
24
Chapter 3
System Description
The input to the Advantech PCI-1711 Card is a standard SCSI port, therefore a
SCSI cable is needed to connect to the ADAM (Advantech Data Acquisition
Modules) wire terminal, which is the interface where the physical I/O cables from
the S4Cplus is connected (see Fig. 31). The wire terminal is an ADAM-3968, a
basic DIN-rail mounting screw terminal module for industrial applications. It has
a 68-pin SCSI-II female connector connection to the Advantech card, and a 68pin screw terminal output.
3.3.6 Sensor
There can be all kinds of sensors applied to this system. At LTH two different
sensors are tested, one called JR3 which is connected directly to the S4Cplus PCI
bus, and one called Optidrive which is connected to the MasterPC. They are both
force sensors, but there is really no limits whatsoever to what type of sensor that
is applicable to the system.
For this implementation an ATI Gamma Force / Torque sensor have been chosen,
simply because it was available for instant utilization. Other options could for
example have been an inductive sensor, a metrology sensor or a range meter.
Fig. 17 ATI F/T Sensor with sensor-board
The ATI Gamma sensor is connected to the PC via an ISA board. However, the
ISA standard is old, and most new computers (like the MasterPC) do not have
25
New Interface for Rapid Feedback on ABB-robots
support for that standard. Hence a second computer is needed when the ATI
Gamma sensor is used (see Chapter 5).
The ATI Gamma Force/Torque 130-10 sensor can measure the force at a rate of
7.8 kHz, and the sensing ranges are; Fz= 400 N, Fx, Fy= 130 N, Tx, Ty= 10 Nm,
Tz= 10 Nm. A closer description of the sensor is available in Appendix B.
3.3.7 Tools
To be able to test the system, two tools which fit on the sensor were developed
and constructed. When the robot pushes on a surface with a limited force, the tool
at the end must have wheels or bearings to reduce the friction in the direction of
the movement.
The first tool used in tests was a tool with a spring and a bearing in the end. The
spring results in a degree of elasticity, which acts as a large bandwidth
dampening system for the automatic control.
Bearing
Spring
Fig. 18 - Tool with spring and bearing.
A second tool was developed when the need for movement in several different
directions during one run was discovered. The result was a tool with a ball in the
end, and it also has a bearing round its own axis, which makes testing of force
movements possible also in this direction.
Ball
Bearing
Fig. 19 New tool with ball end
26
Chapter 3
System Description
3.4 Software
This is an overview of the Software architecture with physical layers. The
diagram is not to be considered as complete software documentation, but as an
overview of the general classes and communication channels, further described in
the text.
Fig. 20 - Software architecture with physical layers
27
New Interface for Rapid Feedback on ABB-robots
3.4.1 SensorControl
The program SensorControl on the SensorPC is used to receive the information
from the sensor and pass it on to the MasterPC through the network. The
foundation of this program is an example program from the sensor manufacturer,
which has been further developed in this Master Thesis and equipped with
network communication possibilities. The program can calibrate the sensor,
display the force and torque applied to the sensor, set the frequency at which the
information is updated and passed on, and establish a connection to the receiving
computer.
Fig. 21 Sensor control, main window
The program admits different display options for the Force and Torque variables,
the three different choises are F/T Units, F/T Counts and Gages. F/T Units shows
the force in Newton, F/T Counts shows the force in counts, and finally, Gages
shows the actual values on the gages in the sensor.
To calibrate the sensor, you can either press the Zero F/T –button or type the
calibration values manually in the Tools -> Sensor Options… menu. The easiest
way is to simply press Zero F/T, however this limits one to only adjusting the
sensor to zero at all forces and torques.
Establishing a connection to the receiving computer is performed by pressing the
Connect-button. Then a small window appears where one enters the IP address
28
Chapter 3
System Description
and corresponding port to the wanted MasterPC, by pressing OK a connection
will be established. The connection between the MasterPC and the SensorPC is a
basic TCP/IP Thread where the MasterPC act as a server.
Fig. 22 Sensor control, connect window
3.4.2 ExtCtrl
ExtCtrl is used to start and synchronise the different classes needed to parse the
ExtRAPID files, upload the Rapid program to the S4Cplus, start the
communication with the G4, receive sensor data from the SensorPC and pass it
on to the G4, and finally control the program steps executed.
When an ExtRAPID program is started (with the ExtRAPID file-argument
correct), the class Main in the package se.lth.robot.extctrl creates instances of
ExtHandler, ExtReceiver, RapHandler, TaskService and ExecState.
ExtReceiver
The class ExtReceiver synchronises the G4 with the S4Cplus. This is done by
receiving feedback from the running loop on the G4 and exporting the feedback
information to ExecState. This information is then passed on to the S4Cplus by
the class RapHandler. The steps executed by ExtReceiver are showed in the Fig.
23.
29
New Interface for Rapid Feedback on ABB-robots
ExtHandler
The ExtHandler class is used for creating the instances that receives sensor data
and sets the sensor data in the ExecState. ExtHandler also controls the update of
CTRLSTEP to the G4. After initialising of the classes SensorData, PStep and
CtrlStepClient, the running loop performs the following steps:
Wait for S4 RAPID program
to start executing
Sleep 1000ms to give S4 program
time to initialize
Read Pstep, update state
Read sensor data, update state
Import CTRLSTEP
Send CTRLSTEP to G4
Sleep a short while to make loop run
at 500Hz.
Fig. 23 Flowchart of ExtHandler (left) and ExtReciever (right)
The active loop runs as long as the program state is not finished, or until it is
interrupted.
RapHandler
The RapHandler class uploads and starts the Rapid program on the S4Cplus, and
then sets the different execution states (e.g. make contact and ramp force) on the
G4. The steps made and the actions taken are shown in the flowchart below.
30
Chapter 3
System Description
Wait for RAPID program
to get parsed.
Enable first instruction
Set loop mode to pos_ctrl
Change loop mode to force_ctrl
Load and start program on S4.
Get next pathstep
Run program until interrupted or
program execution is finished
Wait for S4 buffer space
Wait for new pgmscope
Write Robtarget to S4 buffer
Pgmscope >0?
no
Last
instruction?
no
yes
yes
Set ExecState: pgmscope to S4
Wait for last instruction to run
Wait for runPstep to equal
execPstep
Set loop mode to retract_to_pos_ctrl
Read first instruction
and upload to S4
Wait for ACK, Send ACK to S4.
Change loop to make contact and
ramp force
Change loop mode to pos_ctrl
Wait for ACK
Wait for program to finish.
Fig. 24 - RapHandler flowchart
TaskService
The class TaskService is used only to parse the ExtRAPID file provided when
starting the program. It parses the ExtRAPID file to two different files, fc.prg and
rapmove.prg. The rapmove file contains only the RAPID code that is sent to the
31
New Interface for Rapid Feedback on ABB-robots
S4Cplus, and the fc file contains both the RAPID code and the force control data
which is sent to the G4.
ExecState
ExecState is the class which contains the variables that can be altered during the
process, and can be accessed by all classes in ExtCtrl. It consists of get and set
functions for different states, such as Run path step state, Program parsed state,
Program started state, ExecPStep state et cetera.
3.4.3 Opcom
Opcom is the program which controls the whole process. It consists of four
different parts (S4Cplus Monitoring, G4 Monitoring, Parameter settings and
Activation of external control), and this is intuitively seen when the program is
started, see picture below. When starting Opcom a xml file is used as syntax, the
xml file contains information about parameters needed for Opcom to start
properly.
Fig. 25 Opcom, start window
32
Chapter 3
System Description
S4Cplus Monitoring
The square in the upper left corner is for monitoring the output from the S4Cplus
Control. Here it is possible to see warnings that come, and plainly surveilling the
state of the S4Cplus. Here it is also possible to write and send commands to the
S4Cplus. The link between the S4Cplus and the MasterPC is a SLIP, Serial Line
Internet Protocol, and is further described in the chapter 3.5.
G4 Monitoring
In the upper right corner one can see the output from the G4. As for the S4Cplus,
it is here possible to observe the state of the G4, as well as typing and sending
commands.
Fig. 26 Opcom, all parameters
Parameter settings
In the lower left corner there are a number of parameters that can be set and sent
to the G4. Initially there are only three variables that can be seen, but if the button
“Show All” is pressed, a whole lot of parameters appear. “Get Current” gets the
current values of the parameters from the G4, and “Commit” commits the
changes made on the variables in the program and sends them to the G4.
The parameters are divided into two types, unlocked and hidden. By default, only
unlocked parameters are shown in the GUI as seen in Fig. 25 for the parameters
33
New Interface for Rapid Feedback on ABB-robots
called "Force_Ref", "safety_zone" and "Activate F". Click on "Edit" to change
parameters, and make your changes in the text fields and checkboxes. When
finished, click "End Edit" and "Commit" to send the changes to the controller.
Some useful tuneable parameters are described here:
Unlocked parameters
safety_zone. This parameters will change the maximum allowed change from the
nominal trajectory given by the RAPID program that can be commanded by the
force controller, in millimetres. Example: if safety_zone=10, the robot can only
move a maximum of 10 mm from the nominal RAPID trajectory by the force
controller.
Activate F. After checking this option, the force controller can be activated and
deactivated from the ExtRAPID program. NOTE: This should only be checked
during running of the robot force control, otherwise the robot system should be
considered UNSAFE.
Hidden parameters
Gain is by default a hidden parameter; hidden parameters are configured in the
xml file that is used as syntax when starting Opcom. The controller Gain affects
the sensitivity of the controller. If the force response is too slow, better
performance could potentially be obtained by increasing the value of this
parameter, at the price of decreasing controller robustness. The correct for the
gain is a function of environment- and sensor stiffness, and on robot position
controller bandwidth.
IMPORTANT WARNING: Increasing the controller gain too much
will cause instability of the force control loop! Therefore this value
should be tuned by increasing it in a stepwise fashion, until
satisfactory performance is achieved.
Activating external control
The lower right corner is for controlling the activation of the external control
process. By clicking “Start Submit” the sending of data from the S4Cplus system
to the controller begins. You also need to make sure the modified values
calculated in the controller are copied back into the S4Cplus system, using the
checkbox "Start Obtain". When both these checkboxes are checked, the external
control is running.
34
Chapter 3
System Description
IMPORTANT NOTE 1: After checking "Submit" and "Obtain" the
robot should be considered UNSAFE. Do not enter the workspace
when the robot motors are on!
IMPORTANT NOTE 2: Read through ALL remaining steps in the
instructions (see Appendix B – Running an ExtRAPID program)
carefully before trying to run.
Logging
In the lower right corner you can also find the option of logging. The logging can
only be started if the checkbox “Start submit” is checked. In the box “Logfile”
you type the name and location of the file where the logging is saved. The
number of samples that will be saved can be changed using the field "Datapoints"
(data is obtained at the rate 250 samples/second). The field "Decimation" decides
how many samples will be skipped (Ex: Decimation=10 will save every tenth
sample). When finished selecting logging options, press “Start Logging” to start
the logging. The log file is saved as a Matlab file, and can hence be interpreted
from Matlab.
3.4.4 G4
In this subchapter the software in the G4 is described. In the G4, the Controller
performs its calculations, and here are the files and programmes needed for
regulation described. The controller itself can be defined differently for different
purposes. The control algorithms used for testing the system at LiTH are
described in Chapter Error! Reference source not found.
Roughly, the controller can be seen as an impedance controller with internal
position regulation. It updates the reference position, x_ref, from the Axis
Computer Board in the S4Cplus, calculates a new reference position, x_mod,
based on the Force and Force Reference, and sends the new position back to the
position controller. This is made at 250 Hz.
35
New Interface for Rapid Feedback on ABB-robots
Fig. 27 The control loop between the S4Cplus and G4.
3.4.5 Modification of ABB:s start up script
To be able to run the extended control environment on the S4Cplus it is needed to
modify the computer units start up script. This is done by running a script
developed by Klas Nilsson (LTH). The script is easy to run and gives instructions
during run. First it is needed to run the script on MasterPC, after that just follow
the instructions.
36
Chapter 3
System Description
3.5 Network / Communication
An overview of the networks different connections used in the system. In Fig. 28
it is possible to see how the different couplings are made.
Fig. 28 The systems different connection paths
As can be seen in Fig. 28 there are many different physical network /
communication paths in the system, in the following sub chapters a closer
description of the different standards are available.
37
New Interface for Rapid Feedback on ABB-robots
3.5.1 TCP/IP
TCP/IP is used for transferring information as for example sensor data during
run. The TCP/IP interface is not activated at the G4 at boot-up but after starting
OpCom or sending a start address manually to the G4 the start-up script at the G4
starts the TCP/IP interface by sending a DHCP request on the lab network. More
about the standard can be found at www.wikipedia.org [24].
3.5.2 SLIP/RS232
SLIP is used between MasterPC<=>S4Cplus and between MasterPC<=>G4. The
SLIP connection is used for basic communication and during installation of the
system. Some start-up commands between MasterPC and the different hosts are
also sent via slip, this because the slip is the only connection between MasterPCG4 and MasterPC-S4Cplus that is alive at boot-up and can be used for sending
commands.
Fig. 29 RS232 Cable
3.5.3 RAP/RPC
RAP stands for Robot Application Protocol, and is a protocol that provides an
application interface to the ABB S4Cplus Robot-controllers. The use of RAP
allows the user to control and monitor ABB Robots from an external computer.
The physical connection between the Client and the Server can be either TCP/IP
or SLIP, this is why there is not any RAP/RPC couplings marked on the page
before, and with this connection it is possible to browse through the files in the
Server with a telnet program i.e. HyperTerminal in Windows or minicom in
Linux. It is also possible to execute RAPID commands with this connection if
WebWare is installed in the Client computer.
However, if more advanced functions is needed, like access to variables in the
Server or more advanced File Management Services, the usage of RAP is
demanded.
38
Chapter 3
System Description
3.5.4 I/O (Advantech)
The I/O is used for keeping track of where in the ExtRAPID program you are,
this is called Pstep in the software. The signal comes from the Relay Output on
S4Cplus and is connected to the Advantech card on the MasterPC via modified
Ethernet cable. You can se a schematic picture of the connection in Fig. 30.
Fig. 30 Schematic picture of Advantech coupling
It is often good to use standard cables or at least standard sockets. They make it
easier to move and rearrange the premises where the robot cell is located. At the
system at LiTH, as mentioned earlier, an Ethernet cable is used for the I/O
coupling. Ethernet cables are easy to make and are widely available in different
lengths. Fig. 31 shows a picture of how the modification of the Ethernet
cable/socket is made at the system at LiTH.
Fig. 31 Advantech coupling at DSQC 332
3.5.5 PCI Backplane
The PCI Backplane is a regular PCI bus used in standard computers, available on
more or less every motherboard. The PCI bus can be used to expand the
functionality with ABB’s own system-extensions, for example extra axis
computers or extra I/O computers. Also the PCI bus gives the possibility to
connect externally developed hardware. For example the interface that has been
39
New Interface for Rapid Feedback on ABB-robots
implemented in this project. The PCI bus gives the opportunity to share fast
memory between the ABB system and the extension system connected to the PCI
bus. When using extensions connected to the PCI bus there are some restrictions.
These restrictions will not be described in this report but can be worth
mentioning that it is possible to interfere with ABB’s internal information flow if
the connection is incorrectly made.
3.5.6 Inside S4Cplus controller
The previous sub chapters describe the couplings to the external units in the
system (if you consider the PrPMC-Card as an external unit). Even inside the
S4Cplus controller’s computer system there are numerous protocols used for
transferring information between the different parts. Some of the protocols used
inside are even used between the external units. Fig. 32 shows an overview of the
different protocols used. More thorough information of the containing standards
are widely available on the Internet.
Fig. 32 Communication protocols used inside the controller unit [13]
40
Chapter 4
Chapter 4
ExtRAPID
ExtRAPID
In this chapter the basics of ExtRAPID is described. ExtRAPID is an extended
version of the regular RAPID used for robot programming since decades.
ExtRAPID stands for Extended RAPID and is a language extension developed at
LTH that allows the operator to annotate ordinary RAPID code using a XML-like
syntax. All ExtRAPID code is still conformant with ordinary RAPID and is thus
executable on an ordinary S4Cplus-controller. Executing an ExtRAPID program
on an ordinary S4Cplus-controller will result in that the program is executed with
no consideration taken to the extended parts of the program. When executed on
an enhanced controller the XML-tags are interpreted together with the RAPID
code and all the extended functionality will execute. Information to the following
sub chapters is from Mathias Haage´s description of the ExtRAPID language [3].
4.1 Why ExtRAPID?
The RAPID language mechanism for providing sensor feedback control is too
slow (10Hz) and does only support positional corrections. A mechanism for
handling control using sensor feedback from contact forces and/or torques was
needed. The ExtRAPID language was developed to meet these needs. The
following chapters describe the ExtRAPID language extension for handling force
sensor integration into the RAPID language of the ABB S4Cplus controller using
a prototype force controller. A complete ExtRAPID program and explanation can
be found in Appendix A.
4.2 Basic idea
The basic idea of the language extension is to introduce two new language scopes
into the RAPID language.
• A sensor scope surrounding RAPID code affected by a sensor
• A force scope surrounding RAPID code constrained by force constraints.
The force scope may only occur within a sensor scope, i.e. force constraints can
only be applied in the context of a force sensor.
4.3 Syntax
Ordinary RAPID code is annotated with XML tags encoded as RAPID
comments. An ExtRAPID language scope is encoded as an XML tag. The syntax
for a tag is:
!<tagname name0="value0" name1="value1" ... >
41
New Interface for Rapid Feedback on ABB-robots
Where the XML name-value pairs are here used to set ExtRAPID scope
attributes. Ordinary XML syntax is extended by considering the RAPID
comment sign a whitespace. The RAPID comment sign is thus allowed inside the
definition of an XML tag between name-value pairs. This allows for multiline
XML tags to be expressed non-obtrusively in RAPID code. The following tag is
valid:
!<tagname name0="value0"
! name1="value1"
! name2="value2">
Each tag must have a corresponding endtag. An endtag has the same tagname as
the tag but is preceded with a slash. No name-value pairs are allowed within an
endtag. The syntax for an endtag is:
!</tagname>
The XML tag scope is the text contained between the XML tag and endtag. In
ExtRAPID the tag scope thus contains RAPID code between the tag and endtag.
The ExtRAPID tag is said to influence the RAPID code contained in the tag
scope of the tag. The tag scope is defined to correspond to an ExtRAPID
language scope. For instance:
RAPID code outside tag scope of tag tagname
!<tagname ...>
RAPID code belonging to tag scope of tag tagname
!</tagname>
More RAPID code outside tag scope of tag tagname
The RAPID code belonging to the tag scope of the tag tagname is contained
within the ExtRAPID language scope described by the tag. The RAPID code is
said to be influenced by the tag.
Nested tags are allowed and follows the same rules as for XML. In ExtRAPID
sense nested tags are interpreted as having nested language scopes.
4.4 Sensor scope
The sensor scope binds the enclosed RAPID code to a specific sensor. The sensor
tag marks an ExtRAPID sensor scope enclosed within !<sensor> and
42
Chapter 4
ExtRAPID
!</sensor> tags.
Three tag parameters are allowed:
The value contains a string that is used to identify the
sensor in the underlying system.
id="sensor identifier string"
type="sensor type string"
The value contains a string identifying the type of sensor
used.
The value contains a string that identifies the
S4Cplus sensor extension to use for sensor control. The example ExtRAPID
sensor scope declaration below defines a sensor called optidrive that is measuring
force. The sensor is coupled to the S4Cplus system using the prototype system.
interface="interface identifier string"
!<sensor id="optidrive"
! type="force"
! interface="LTH S4Cplus Control Extension">
!</sensor>
Bind the enclosed RAPID code to the sensor identified in the system as optidrive.
The sensor is of type force and the software responsible for integrating the sensor
measurements into the S4Cplus controller system is the LTH S4Cplus Control
Extension.
4.5 Force scope
The force scope binds the enclosed RAPID code for execution influenced by
force control. The force tag marks a force scope. The tagname is force. It is only
possible to define one or several force scopes within a surrounding sensor scope.
It is not allowed to define a force scope outside a sensor scope. The force scope
defines a force execution block and starts with a buildup phase, is followed by a
process phase and finally ends with a retract phase. The tag contains parameters
for all three phases.
4.6 Build phase
These parameters are concerned with defining a surface search and defining a
force buildup ramp function.
surfaceSearchDirection="1,0,0" The direction to move when searching for surface
contact at the beginning of the force scope. The search direction is given in the
tool frame and must currently be in the x direction.
43
New Interface for Rapid Feedback on ABB-robots
The speed to use when searching for surface
contact. Currently the value is not used. The controller searches for surface
contact using a fixed speed.
surfaceSearchSpeed="10mm/s"
The force controlled direction. The other directions are still
position controlled. Direction is specified in the tool frame and must currently be
set to x direction.
forceDirection="1,0,0"
buildForceFunc="upramp" After
making surface contact, the force is built to a
wanted level using this path. Currently only the ramp curve is available
The time period for building the force. Here the force is
built during 1000ms measured from surface contact. Time must be given in
milliseconds.
buildForceTime="1000ms"
buildForceFinalValue="150N" Force
is built up to this level.
buildForceContactThreshold="30N" Force
threshold for determining surface contact.
Start executing ExtRAPID move instructions before
force is built up to final value. Normal behavior is to stand still until force has
been built up. This value allows the tool to start moving while force is building.
buildForceTriggValue="130N"
The maximum amount of time to search for a surface
contact before signaling an error.
buildForceTimeout="30s"
4.7 Process phase
These parameters define the surface force control.
Force shape to follow during the process phase
of the force scope. Constant force functions are accepted as well as per
instruction functions, see description stepwise section later.
processForceFunc="constant 150N"
This attribute is not used. It is intended for specifying
force-path velocity relationships.
processVelocityFunc="void"
4.8 Retract phase
These parameters define the force ramp function for leaving the surface.
retractForceFunc="downramp" The shape of the function to use during retract phase
for declining force. Currently only the ramp shape is allowed.
retractForceTime="1000ms" The time period for declining force to zero.
retractForceNoContactThreshold="15N" Force threshold for deciding when tool has
lost surface contact.
44
Chapter 4
ExtRAPID
The example force tag below defines a force scope that starts searching for a
surface in the tool x direction with a search speed of 10mm/s. If the surface has
not been reached within 30 seconds the operation is aborted. When surface
contact has been established (determined through buildForceContactThreshold),
force is ramped from 30N to 150N along the forceDirection axis during 1000ms.
When force has reached 130N a signal is sent to the RAPID system to start
executing RAPID surface path MoveL instructions. The RAPID instruction for the
surface path is executed influenced by the processForceFunc, which specifies a
constant force constraint. After the last surface path MoveL instruction has been
executed the force is ramped from 150N down to 15N (determined by the
retractForceNoContactThreshold), after which the tool is moved slightly off the
surface along the forceDirection direction.
!<force surfaceSearchDirection="1,0,0"
! surfaceSearchSpeed="10mm/s"
! forceDirection="1,0,0"
! buildForceFunc="upramp"
! buildForceTime="1000ms"
! buildForceFinalValue="150N"
! buildForceContactThreshold="30N"
! buildForceTriggValue="130N"
! buildForceTimeout="30s"
! retractForceFunc="downramp"
! retractForceTime="1000ms"
! retractForceNoContactThreshold="15N"
! processForceFunc="constant 150N"
! processVelocityFunc="void">
MoveL C003, spd003, z10, stool;
MoveL C004, spd004, z10, stool;
!</force>
4.9 Restrictions
The prototype ExtRAPID parser and runtime system imposes some restrictions
on the force tag. They are listed below:
• The parser requires all units to be stated as in the example.
45
New Interface for Rapid Feedback on ABB-robots
• The surfaceSearchDirection must be the tool x direction.
• The surface search speed is built into the force controller and is currently
not used.
• The forceDirection must be the tool x direction.
• The processForceFunc must be constant.
• The buildForceFunc must be upramp.
• The retractForceFunc must be downramp.
• The processVelocityFunc must be void.
• The prototype imposes some restrictions on the execution of a force tag.
They are listed below:
• Speeddata and zonedata parameters are considered per force scope. In the
example above the force scope uses the speeddata and zonedata of the first
MoveL instruction. The second MoveL instruction is executed using the
speeddata and zonedata of the first instruction.
• Tooldata is not considered. Tooldata is currently hardcoded into the
RAPID runtime system and can only be changed by editing this file.
4.10 Stepwise force function
This force function allows the user to specify force individually for each MoveL
instruction executed during a force scope. The force scope using a stepwise force
function:
!<force surfaceSearchDirection="1,0,0"
! surfaceSearchSpeed="10mm/s"
! forceDirection="1,0,0"
! buildForceFunc="upramp"
! buildForceTime="1000ms"
! buildForceFinalValue="40N"
! buildForceContactThreshold="10N"
! buildForceTriggValue="35N"
! buildForceTimeout="30s"
! retractForceFunc="downramp"
! retractForceTime="1000ms"
! retractForceNoContactThreshold="10N"
46
Chapter 4
ExtRAPID
! processForceFunc="stepwise"
! processVelocityFunc="void">
MoveL C003, spd003, z10, stool;
!<param forceFunc="constant 40N",
buildForceStartValue="40N",
buildForceFunc="upramp",
buildForceTime="500ms">
MoveL C004, spd004, z10, stool;
!<param forceFunc="constant 20N",
buildForceStartValue="40N",
buildForceFunc="downramp",
buildForceTime="1000ms">
!</force>
The following points should be noted:
•
processForceFunc="stepwise"
The process force function in the force tag is
called stepwise.
• Each MoveL instruction has been extended with a param tag containing
force parameters.
Description of force parameters in the param tag:
•
forceFunc=”constant 20N”
The force function to use during the MoveL
execution.
The start force value used as reference before
buildup has started. In the example tag given previously it is taken as the
constant force function value of the previous MoveL instruction unless it is
the first MoveL instruction of the force scope, then it is the value of the
buildForceFinalValue parameter.
•
buildForceStartValue=”40N”
•
buildForceFunc=”downramp”
or
buildForceFunc=”upramp”
The build force
function to use.
•
buildForceTime=”1000ms” The time to build force. Do not use zero as build
force time. Always allow for some building time.
47
Chapter 5
Chapter 5
Case study
Case study
To test the new interface that has been implemented at LiTH, a case study was
performed to develop a methodology for making a successful run on a previously
unused robot cell. The case study was also used to get a hint of the performance
of the newly implemented interface, as well as the problems that can appear when
working with it. The performance of the system depends on which controller that
is used during execution along with the sensors performance and possible delays
due to how the sensor is implemented. This chapter also describes how to install
and configure the different parts involved in the system. Installing the ABB
specific parts as BaseWare for example are not described here due to that it is
well documented in ABB’s own manuals.
5.1 Hardware installation
First off in implementing the system is to install all the hardware described in
chapter 3.3. The hardware is needed to make the new interface work with a
regular ABB S4Cplus controller. Since the S4Cplus can control many different
types of robots, the type of robot is irrelevant from the hardware perspective.
Clean system
Disassembly
S4Cplus controller
unit
S4Cplus computer
unit loose
Remove side-cover
on S4Cplus unit
Replace Ram-disc
with Flash-disc
Join the G4 PowerPC
with the PMC-PCI
card
Connect the PMCPCI card with G4
PowerPC to PCI-bus
Reassemble the
S4Cplus controller
Install Advantech
card in MasterPC
Install your chocie of
sensor and sensorboard
Mount your tool
Connect needed
cables
Hardware
ready
Fig. 33 Flowchart of hardware installation
This subchapter describes how to install the hardware. The hardware needed is,
as mentioned earlier:
• G4 PowerPC
49
New Interface for Rapid Feedback on ABB-robots
• PMC-PCI
• Flash Disc
• Advantech PCI-1711
• Sensor
• Tool
Some of the hardware should be installed inside the S4Cplus controller unit and it
is necessary to disassemble the controller unit and remove all the cables
connected to the computer unit. Remember to use ESD protection when working
inside the computer unit. The computer unit is easily opened by removing the
screws (torque screws). Only the screws along the sides have to be removed.
When the screws are removed you can remove the side cover and you should
have something that looks like Fig. 34 in front of you. To install the formatted
flash disc is easy. All you have to do is to replace the ram disc with the flash disc.
Next part in the installation is to connect the G4 PowerPC to the PMC-PCI card.
This is done by pressing them together. Make sure that the PMC interface
matches correctly. Else it is possible to damage one or perhaps both cards. When
the G4 PowerPC and the PMC-PCI card are connected to each other they are
ready for installation in the computer unit. The PMC-PCI card should be installed
in the same half of the PCI bus as the Main computer. When G4 PowerPC, PMCPCI-card and the flash disc are installed in the computer unit the S4Cplus unit is
ready for reassembly.
Fig. 34 Inside S4Cplus computer unit
50
Chapter 5
Case study
After completing the installation in the S4Cplus controller unit it can be wise to
install the Advantech card in the MasterPC to enable the output unit at the
S4Cplus unit to the MasterPC. Installing the Advantech card out of a hardware
perspective should not be a problem since it is a standard procedure for installing
expansion cards in PC’s. When the parts in the S4Cplus unit and the ones in the
MasterPC are done it is time to install and connect the sensor. As mentioned in
chapter 3.3.6 an ATI Gamma Force / Torque sensor was used simply because it
was available for instant utilization in the lab. The ATI Gamma sensor has an
ISA board that is connected to the PC. However, the ISA standard is old, and
most new computers (like the MasterPC) do not have support for that standard.
To solve that problem, an extra computer with an ISA slot is used and that
computer collects sensor information and then passes it on to the MasterPC. The
installation of the sensor can vary a lot so it is not described more here. In Fig. 35
it is possible to see the sensor with mounted tool.
Fig. 35 Close up of sensor and tool
The sensor needs a tool to be useful in the case study, two different types of tools
have been used during the implementation at LiTH, and the tools can be seen in
chapter 3.3.7. In Fig. 36 you can see the complete demo setup used during the
case study at LiTH.
51
New Interface for Rapid Feedback on ABB-robots
Fig. 36 Complete demo setup
5.2 Operating system
What is called MasterPC throughout the report acts like the brain in this system.
In this chapter it is described how the operating system has been installed and
other parts of the software environment necessary for the system to act as wanted.
Fig. 37 Flowchart of Operating system installation
The MasterPC, at LiTH, is installed in such way that dual boot is possible
because some of the software that comes with the ABB robot only is available in
versions that is supposed to run in Windows environment. The other half of the
dual boot system is an installation of Fedora Core 2(Linux kernel). In this chapter
it is only described the procedure of how to install the Linux system, because the
52
Chapter 5
Case study
Windows XP installation is a standard installation. One basic thing that is worth
mentioning is that it eases the process drastically if installing the Windows XP
system first because it is often easier for beginners to configure the dual boot
screen during the Linux installation. One thing to keep in mind when installing
XP is that all of the hard drive can not be used. In Fig. 38 is an illustration how
the hard drive can be partioned
Fig. 38 Partition table, MasterPC
A FAT32 partion is used as swap partion for transferring files between the XP
installation and the Linux installation. Today it is possible to reach even an
NTFS-partion from Linux but some of the drivers making that available does
only make it possible to mount the NTFS partions as read-only in Linux. There
are drivers that have read-write capabilities but some have experienced file
corruption on the partitions after a while. So it can be wise to use FAT32 for that
partition to minimize the risk for errors later on. The way this hard drive is
portioned is only one way to do it and should only be considered as a
recommendation!
• NTFS
Used in Windows NT-based OS.
• FAT32
File system used in older Windows
versions.
• ext3
File system used in Linux.
53
New Interface for Rapid Feedback on ABB-robots
• Boot
Partition that contains information used
during boot.
• Linux-swap
Expansion of the computer's physical
memory
5.2.1 Linux
There are some rather important things to keep in mind when installing Linux, in
the following sub chapters it is described in short guidelines how the different
parts needed in the system can be installed. Most of the parts described in the
following chapters are not critical to do during the installation but the things that
are possible to do during installation can be wise to do then.
Below is a list of some packages that are more or less necessary for the Linux
installation to function properly. If you are an experienced Linux user you
probably have packages that you prefer and there should not be any problems
installing the ones you like.
• NcFTP
• Java 1.4.2
• Rxtx 2.05
• Dnsmasq
• DHCP server
5.2.2 DHCP server
The DHCP-server takes care of the internal network in the lab. It gives the other
computers fixed IP addresses and gives room for temporary computers by sharing
dynamic IP-addresses to them. This gives the possibility to use for example a
laptop in the network.
About how to configure the DHCP-server there is lot of information on the
Internet [6][7]. In Appendix F there is an extract of our dhcpd.conf which is the
configuration file that tells the DHCP service how it should act. It is important to
remember to activate the service for DHCP, otherwise it will not answer to boot
requests made on the internal network.
54
Chapter 5
Case study
Below we are going to discuss some important things to keep in mind to get the
internal network to act as wanted, for example there are some important things
that must be there so the G4 will act as wanted when booting. Despite that the
other computers do not need specific configurations it is good to keep some order
anyhow. The units that get fixed IP addresses in the system at LiTH are the G4,
the SensorPC and the S4Cplus unit. Other units that are connected to the network
will get dynamic IP under given conditions that are specified in dhcpd.conf. It is
important that the DHCP-server listen to only the internal network interface
because the MasterPC should not answer on boot requests on the external
network. To make it listen to only one network interface is done by this row in
dhcpd.conf:
DHCPD_INTERFACE = "eth1";
What’s important to keep in mind when configuring the DHCP server is that the
G4 must have the “right” host name as option in the dhcpd.conf file, the host name
that the G4 gets when booting is used as a part of the directory when it should run
its boot script. It is also important to send the IP number to the computer where to
make the NFS mount during boot. Our MasterPC is the same as the DHCP server
which makes it easier. We do not have to send the IP address to the computer
where to find the NFS export because it is the same computer as it got its own IP
address from and when that is the case, it looks there first. To illustrate how the
options could be written we have chosen to use them in our dhcpd.conf even
though they are unnecessary in the system set up at LiTH.
This is how the assignment of the fix IP to the G4 is made:
host prpmc3 {
hardware ethernet 00:01:AF:04:B2:3B;
fixed-address 192.168.0.200;
option host-name "prpmc3";
server-name "master.robot.lith";
next-server master.robot.lith;
}
What could be seen in the text above is that the MAC address that matches the
one given in dhcpd.conf would get 192.168.0.200 as IP when it asks for an IP on
the internal network. It could also be seen that the DHCP-server gives the unit the
hostname prpmc3, we have mentioned earlier that this would be a part of the boot
string used when the G4 tries to boot. Server-name and next-server gives which
55
New Interface for Rapid Feedback on ABB-robots
computer the G4 should try to boot from, in this case it would try to boot from
master.robot.lith.
5.2.3 Java
Installing the right java compilators and corresponding runtime environment
needed for the system to work properly could fuss a lot if it goes bad. It could for
example be major version conflicts. Below is a quite short description of a few
items that should give understanding of the importance of making this properly.
The different java packages that are needed are:
• Java sdk
• javax.comm (rxtx)
The java version installed at the system at LiTH is j2sdk1.4.2_05 and is installed
as the instruction that is available at Sun’s homepage [14]. Hence that there are
some different version to choose from, the available version at the moment is
“RPM in self-extracting file” or a “self-extracting file”.
The system at LiTH is built round one java compiler and corresponding run time
environment, because of that it could be wise to simplify as much as possible by
auto loading the environment that should be used. If there would have been
multiple environments present it had been best to keep the configuration as
flexible as possible so it is possible to choose which version to run every time it
is needed. The only thing needed for the wanted java environment to start at startup is to make a script file which point to the directory where the java files is
placed. In the system at LiTH the row that makes this looks like this:
export PATH=$PATH:/usr/java/j2sdk1.4.2_05/bin
This row can be placed in a executable sh-file in the directory
make it run every time the system boots up.
/etc/profile.d
to
The javax.comm package is important to get the serial communication through
SLIP to work as wanted, without that is not possible to use the serial interface in
the java environment. The serial interface is used for supervision of the G4 and
S4Cplus system during boot and is used to send basic commands to and from
different units. The version used at LiTH is:
rxtx-2.0.5-linux.tar.gz
When using the above version it should not be any problem to install javax.comm
to work as wanted. Just decompress the file and copy the contained files to the
directories in the chart below.
56
Chapter 5
Case study
• *.so files copies to /usr/java/j2sdk1.4.2_05/jre/lib/i386
• jar.files copies to /usr/java/j2sdk1.4.2_05/jre/lib/ext
• javax.comm.properties copies to /usr/java/j2sdk1.4.2_05/jre/lib
5.2.4 Installing and Use of Comedi
The IO system at LiTH is built around an Advantech 1711 and this chapter will
describe some things to keep in mind when installing the driver. The version of
Comedi which is the driver package for Advantech in Linux used at LiTH is
Comedi 0.7.69, which can be downloaded from the Comedi Homepage [8].
Before trying to run the installation program it is is necessary to make sure that
the configuration file that your kernel source uses is named .config and is placed
in the top level of the kernel source directory. This is made by running:
cp kernelxxxx.config .config (where xxxx represents the kernel version)
For the system at LiTH a CVS snapshot of the Comedi driver is used, the regular
versions seems to have some problems when being used with Fedora Core 2.
When building drivers from a snapshot it is necessary to generate a configuration
file by your own. This is made by running:
./autogen.sh (located in the source directory of comedi)
When generating the configuration file it can be according to the latest
README.CVS wise to run autogen.sh twice. Some problems have aroused when
only running it once.
After installation you have to associate the driver with the correct module. This is
done by running the command:
comedi_config /dev/comediX pci1711
This could be wise to do in start-up script for automatic association of driver and
module. When correct driver is loaded and has been associated with the correct
module the command dmesg should print something looking like the text below,
of course more text would be visible but search for rows containing Comedi:
comedi: version 0.7.69 - David Schleef comedi0: adv_pci1710: board=pci1711,
b:s:f=0:11:0, io=0xd000, irq=5.
5.2.5 Adapting Advantech to fit LTH’s software [9]
To be able to use the software developed at LTH we have to use a script during
boot that parses a configuration file that contains mapping information about the
used IO-card. The configuration file tells what number in Comedi language the
57
New Interface for Rapid Feedback on ABB-robots
different sub devices have and which pins that represent the different input
signals in the case when using the Lund software we only use one sub device and
further more just half of the available channels on that sub device. Here is a part
of our configuration file. The script used for parsing the file can be seen in
Appendix G.
modules adv_pci1710
configure /dev/comedi0 pci1711
ain 0 /dev/comedi0 0:0
ain 1 /dev/comedi0 0:1
ain 2 /dev/comedi0 0:2
ain 3 /dev/comedi0 0:3
ain 4 /dev/comedi0 0:4
ain 5 /dev/comedi0 0:5
ain 6 /dev/comedi0 0:6
ain 7 /dev/comedi0 0:7
ain 8 /dev/comedi0 0:8
5.3 Software installation
In the previous sub chapter the OS environment and the parts connected to it
were described. In this chapter how to install the software environment needed
for executing and controlling programs during run is described. How to configure
the environment to interact with the other parts of the system is described in
chapter 5.5. The software parts that will be described in quite short terms are:
• ExtCtrl
• SensorControl
• Opcom
• G4
The perhaps most important software environment needed in the interface is the
ExtCtrl-environment that takes care of for example parsing the ExtRAPIDprogram and starts communication with the G4. More information about it is
functionality is described in chapter 3.4.4.
58
Chapter 5
Case study
Fig. 39 Flowchart of software installation
The installation depends on how the ExtCtrl-environment is packed, in the case at
LiTH it was a standard compressed file so it was only necessary to decompress it
to the suitable directory. It can be wise to gather the different software
environment in logical hierarchy. There are only two files in the ExtCtrlenvironment that needs to be controlled and changed if needed. These are
/environment and /extctrl/src/makefile. What is needed to be changed can differ but
probably it is needed to change the directory reference to the different raprpc
directories in the environment-file. In the makefile it should be controlled that the
directory reference to the wanted java environment are correct.
The sensor-environment depends on how the sensor is implemented at the current
system. At the system at LiTH a SensorControl-environment was written that
integrates with the ExtCtrl-environment at the MasterPC but the SensorControl is
also installed at the SensorPC at LiTH. Because, as mentioned earlier, the sensor
is only possible to connect to from a computer with ISA bus. The SensorControl
environment on the SensorPC is further described in chapter 3.4.1.
When installing the Opcom environment it should not arise any big problems.
There is no makefile for Opcom yet so there are no directory references that have
to be changed. You just have to pay attention to where Opcom is being installed.
The G4-environment is also quite easy to install, it is only necessary to make sure
that the G4 can mount the NFS-directory that it is told to. When adding the
directory to the NFS-share, remember to start the services needed for NFS to be
available.
59
New Interface for Rapid Feedback on ABB-robots
5.4 Control algorithms
The controller used for the Case Study is a very simple controler, used only for
these experimental trials. If more advanced functions with higher demands on the
regulation is required, a model for the specific need can easily be developed in
Simulink, and then implemented in the system.
The equation for the control algorithm is:
G ( s ) × ( x _ mod(s ) − x _ ref ( s )) = T ( x) × ( F ( s ) − F _ ref ( s ))
Where
F = [the measured force]
x = [the position (the tools x position)]
T ( x) = [a Jacobian to convert different representations of position / orientation]
G ( s ) = [a 2 : nd order impedance ] = Ms 2 + Ds + K
M, D and K are diagonal matrixes of impedance parameters for the different
degrees of freedom. Apart from these parts, there are a lot of kinematics for
converting to joint angels and transforming between different coordinate systems.
Fig. 40 - Simulink model of the controller
60
Chapter 5
Case study
5.5 Configuration methodology
In Fig. 41 is a flow chart that shows a configuration methodology that is a result
of the work done at LiTH during the autumn 2004. To be able to work with the
system this way it is necessary to have knowledge of the different parts of the
interface. In the methodology it is presumed that the hardware and software is
correctly installed and working along with all the communication paths
physically available.
Hardware implementation
ready.
Sofware installed,
(unconfigured)
Control/Change IP’s
in Opcom
Control/Change
hostnames in Opcom
interface
Compile changed
Opcom files
Control/Change IP
address in extctrl
Compile extctrl
environment
Control/Change
stork.conf
Make sure startscript
for comedi is inplace
Configure the XML
file for Opcom
Create Directory on
S4C plus
Measure your tool
Make ExtRAPID
program
Calibrate sensor
Run Opcom
Run ExtRAPID
program
END
Fig. 41 Configuration methodology flowchart
61
New Interface for Rapid Feedback on ABB-robots
As seen in Fig. 41 there are numerous steps that are involved when configuring
the system. The containing steps need more description and such description is
available below. Description of the different steps of the methodology is made to
explain in what order the tasks should be performed.
Hardware implementation
ready.
Sofware installed,
(unconfigured)
The starting condition for this methodology is that
the hardware is fully implemented and the software
needed for the system is installed but not
configured.
Control and change IP means that you have to
check that the IP addresses configured in the
Opcom
interface
match
your
network
configuration. There is one file you have to change,
IRB2400Control.java, which is located in the
source directory of Opcom.
In this step you have two options either you change
the hostname for the G4 in the Opcom source files
to the same name, or you bind the booth different
nicknames to the same IP, this can be done very
easily in Linux.
Compile the source files that you have changed,
important step, otherwise none of the changes will
be noticed during execution.
The IP address to the S4Cplus unit must be
changed in rapclient.java so the masterPC could
communicate with the controller unit.
Compile the extctrl environment to make changes
take effect.
Here you have to control and perhaps change in the
stork.conf file for the Advantech card to function
properly. More info about this could be found in
chapter 5.2.5.
62
Chapter 5
Case study
Here you have to make sure that the start script that
parses the stork.conf is placed in a directory that
makes it execute everytime the masterPC boot up.
Here you have to configure the xml-file used as
syntax when starting Opcom, use one of the
existing xml-files and adapt it to your system. What
you have to change in the file is: IP and RS232.
You have to create a directory on the S4Cplus unit.
The directory should be named ExtRAPID and be
placed at the root of the flashdrive in the S4Cplus
unit.
You have to measure your tool to be able to use it
when making RAPID programs, so you can define
how much the TCP should be moved and rotated.
Program an ExtRAPID program that you can use to
test the system. Use the example in Appendix A
and modify it according to regular RAPID syntax
and the information available in chapter Error!
Reference source not found..
Calibrate the sensor in the rotation it is going to
have when executing the force scopes. When using
more advanced regulators there is the possibility to
use gravity compensation.
Run Opcom as described in Appendix B, a closer
description of the different parts of Opcom could be
seen in chapter 3.4.3.
Run the ExtRAPID program as the instructions in
Appendix B.
END
After the ExtRAPID program has executed the task
of making the system run is ready
63
New Interface for Rapid Feedback on ABB-robots
5.6 Performance
To test and evaluate the interface and the complete system there was a few tests
conducted at LiTH, for example tests to run an ExtRAPID program that pushed
with a given force on a plane surface. Since the major part of this Master Thesis
was to implement the interface, the tests performed on the system became very
limited. Only a few simple tests were made to explore the general functionality of
the system.
Fig. 42 Test run with constant force 50 N, x axis is seconds, y axis is Newton.
Fig. 42 shows a test run with an ExtRAPID program that should make a run over
a plane surface with a constant force of 50 N. By varying the parameter Gain in
Opcom, described in chapter 3.4.3, you can get quite differing results, but with a
Gain value that matches the speed and tool used, it is possible to achieve
acceptable results. In the figure you can see that the robot starts pushing on the
surface after 17 seconds, and pushes with 50 Newton on the surface.
Letting an extra computer take care of the sensor information, as in our case,
sometimes leads to loss in reliability and bad performance in the end due to the
possible delays depending on heavy traffic on the internal network. The worst
case is that collisions occur and packets with sensor information will get lost. But
it is probably better for the performance that one single information packet get
lost than that a displacement of all the following packets occur.
64
Chapter 5
Case study
Fig. 43 Sensor delay
Some quite simple evaluation tests were made at the complete system at LiTH
with the described type of sensor implementation. These tests showed that the
delay was insignificant. In Fig. 43 the sensor values and the robot motor joint
radians are shown, and from this we saw that the sensor information came
without delay as the motors changed direction.
The system was also tested work pieces that weren’t plane, to explore the
adaptivity to unknown environments. Two different surfaces was used, one
rounded and very complex surface, and one with a triangular shape on the center
of the work piece (see Fig. 44 Adaptive movements on an unknown shape). In
both tests the movements adapted well to the unknown environment, but
unfortunately the controller used in this Case Study wasn’t developed for this
type of task. Therefore the force on the work piece increased up to 100N during
the ascending. If the controller is further developed, these types of tasks will be
performed with ease, simplifying the programming of the robot significantly.
Fig. 44 Adaptive movements on an unknown shape.
65
New Interface for Rapid Feedback on ABB-robots
5.7 Problems
Some problems came up during the case study that was conducted at LiTH. Many
of the problems had to do with network and the communication paths in the
system. This sub-chapter describes some of the problems, where you have to, for
example, change the IP addresses in different files and along with that some parts
did not work as expected.
The way to address the clients in the system is different in the software
environments described earlier. There are different address methods inside the
same software environment as well which can be experienced as a quite odd
choice. The G4 PowerPC-card, for example, appears with different host names in
the different java classes in the Opcom environment from Lund. In the version
we have booth prpmc3 and prpmc1 exists. It should be prpmc3 but you can
circumvent that by adding prpmc1 as a nickname for the host prpmc3 in the DNS
server at MasterPC (so they booth point to the same IP address). This should be
easy fixed using the addresses specified in the configuration file for Opcom
Problems also occurred when it was time to connect the S4Cplus outputs to the
Advantech card on the MasterPC. The output signal is not grounded when it is set
to zero. There are many ways to solve a problem like that. One is to make an
extra circuit that corrects the signal levels so zero is ground. Because of how the
Advantech card is designed there are ways to solve it without using extra
material. In this case the signal was inverted twice, once in the controller
software and once due to inverting the feeding voltage. This will make the signal
appear as wanted when read at the Advantech card input.
We also had complicated problems with ABB’s options when at the start-up of
the project. One of the options mentioned earlier in the report changes the
authentication method used when connecting to the robot with low-level
programming. The options involved in the problem were RAP Communication
and FactoryWare Interface. FactoryWare Interface has the disadvantage that it
demands higher level of authentication when connecting to the robot, but after
some research about what the different options do we came to the conclusion that
the FactoryWare Interface is not needed in the system at LiTH.
66
Chapter 6
Chapter 6
Conclusion
Conclusion
The new system for rapid feedback control is a highly complex system, possible
to install in existing robot cells, and enables real-time sensor feedback to the
robot controller. However, the system is not yet fully developed, some limitations
still exists in the system, and a lot of issues need to be considered before it can
reach the market in other than specific applications.
Some of the issues intended to be brought up in this conclusion are Installation
and Configuration, System Properties and Safety.
When analyzing the system, one has to remember that this system is brand new
and still undergoing development. Therefore the demands on simplicity as well as
performance can not be as high as if the system was bought off the shelf.
Installation and Configuration
The installation of the system needs to be simplified. The guidelines and
methodology developed during this Master Thesis and shown in this report is a
good start, but the fact that a methodology needed to be developed at all shows
that the installation and configuration process is everything but intuitive.
The main problems in installing the hardware have been when the devices and
options not conform exactly to those used in the system at LTH. This could easily
be avoided by specifying exactly what options and which devices that should be
used in the system.
When configuring the system, one has to go through a lot of files and change
hostnames and IP addresses directly in the source code, and then recompile the
files. When being an advanced user this is acceptable, but for future use, defining
these configurations globally must be possible.
System Properties
The system at LiTH has various limitations. Some of the limitations have already
been removed from the system at LTH, and some have been considered but not
yet implemented.
In the system at LiTH the regulation can only be in one direction, the x-axis of
the tool. This means that the regulation is only in 1DOF, and that is a major
limitation. However, at LTH another type of sensor is used, and 6DOF regulation
has already been tested on the system with that specific sensor (JR3).
67
New Interface for Rapid Feedback on ABB-robots
Improvement suggestions to the system:
• Not using external computer – For this system an external computer is
needed. Preferably everything should be in the G4 PowerPC.
• Extending control to 6DOF – Either the JR3 sensor needs to be included
in the LiTH system, or the system needs to be altered for 6DOF control via
the MasterPC.
• Adding variable control speed –The controller needs to be improved, and
one thing that would be desirable is to add variable control speed. This
change would make the regulation more flexible for user input.
Safety
One of the issues which have to be considered is safety. The external hardware
needs to be as reliable as the robot controller, and for that there has to be some
form of standard on the hardware.
Also, since the normal emergency stop need to be bypassed (at the specified
boundaries) for the new system to work, some form of alternate security needs to
be available.
Possibilities
The possibilities for this system are vast. Tasks that an industrial robot could not
perform earlier are now possible through the use of real-time sensor feedback.
Examples of such tasks could be grinding, drilling and performing general tasks
that require adaptive movements, such as the adaptive movement explained in
Fig. 44, Case Study.
Fig. 45 Extreme accuracy with sensor feedback
Absolute accuracy in Industrial Robots today is better than 1 mm (Volvo Cars),
and High-Accuracy Robots today can reach absolute accuracy of down to 0.2 mm
(ABB, KUKA). Experiments at LiTH have shown that accuracy can be < 50 µm
68
Chapter 6
Conclusion
(!) with rapid feedback and metrology sensor on a standard ABB IRB4400 robot.
The potential for a robot with this extreme accuracy is large, especially if the
accuracy can be combined with force control. That, on the other hand, demands a
lot of work to achieve and a lot of development on the functions of the controller.
Avoiding collision and following objects with distance sensors or inductive
sensors is also possible due to this real-time interface, so the newly implemented
interface brings the complexity of tasks that can be performed by a regular robot
to new levels.
Fig. 46 Following objects and grinding with standard robots
The final conclusion for this system is that it makes industrial robots more useful
in tasks for manufacturing. It has great potential, since it makes production with
robots exceedingly flexible and dynamic.
69
Chapter 7
Chapter 7
Bibliography
Bibliography
[1] http://www.proviking.se, 2004-10-09
[2] http://www.autofett.org, 2004-10-10
[3] Haage Mathias (2003). RAPID Force Extension Proposal, 4th DRAFT
Department of Computer Systems, Lund Institute of Technology, Lund.
[4] Olsson Tomas (2004). Feedback Control and Sensor Fusion of Vision and
Force. Report ISRN LUTFD2/TFRT--3235—SE. Department of Automatic
Control Lund Institute of Technology, Lund.
[5] A Blomdell, G. Bolmsjö, T. Brogårdh, P. Cederberg, M. Isaksson, R.
Johansson, M. Haage, K. Nilsson, M. Olsson, T. Olsson, A. Robertsson, J. J.
Wang, Extending an industrial robot controller with a fast open sensor
interface implementation and applications, Robotics and Automation
Magazine, 2005 (in press).
[6] http://www.siliconvalleyccie.com/linux-hn/dchp.htm, 2004-10-10
[7] http://www.zevils.com/cgi-bin/man/man2html?dhcpd.conf+5, 2004-10-10
[8] http://www.comedi.org/, 2004-10-10
[9] http://www.control.lth.se/~andersb/linux_in_control/, 2004-11-02
[10] ABB Automation Technology Products AB Robotics. Product Specification
RobotWare Options for BaseWare OS 4.0. 3HAC 9218-1 Rev.2.
[11] ABB Automation Technology Products AB. Product Manual S4Cplus
[12] ABB Automation Technology Products AB. Product Specification IRB 4400
[13] ABB Automation Technology Products AB. Ethernet Services User’s Guide
[14] http://www.sun.com, 2004-10-10
[15] Sunnanbo, Albin (2003). Laser feedback control for robotics in aircraft
assembly. Report: LiTH-ISY-EX-3470-2003. Department of Mechanical
Engineering, Linköping University, Linköping.
[16] Kihlman, H., Sunnanbo, A., Loser, R., Von Arb, K., Cooke, A., (2004)
"Metrology-integrated Industrial Robots – Calibration, Implementation and
Testing", 35th International Symposium on Robotics, Paris-Nord Villepinte,
France, March 23-26
[17] ABB Robotics AB. RAPID Referensmanual, Systemdatatyper och Rutiner,
3HAC 7775-1 för BaseWare OS 4.0. Västerås
[18] http://www.advantech.com, 2004-10-01
71
New Interface for Rapid Feedback on ABB-robots
[19] www.alvsjodata.nu, 2005-01-10
[20] www.ieee.org, 2005-01-10
[21] www.interfaceconcept.com, 2005-01-11
[22] www.robotics.utexas.edu/rrg/learn_more/history/, 2005-01-11
[23] www.m-w.com, 2005-01-11
[24] www.wikipedia.org, 2005-01-11
[25] Nof, Shimon Y. 1999. Handbook of industrial Robotics, 2nd ed. John Wiley
& Sons. ISBN 0471177830
[26] ISO Standard 8373:1994, Manipulating Industrial Robots – Vocabulary
[27] http://www.swira.se, 2005-01-03
[28] NyTeknik magazine, 1981:50
72
Appendix A
Appendix A
ExtRAPID An Example
ExtRAPID An Example
The syntax of ExtRAPID is easy to understand, and is a very intuitive language
for describing sensor feedback control on a robot i.e. the ABB IRB4400. It
contains not only the Rapid code for moving the robot, but also how the sensor
feedback should be treated. The following Code Example describes how the
programming language works.
----Here starts the example---!!! NOTE: only robtargets are used in force scopes. Speeddata and zonedata are used from the first instruction.
MODULE grindingtask
[email protected]@
[email protected]@ VERSION:1
[email protected]@ LANGUAGE:ENGLISH
!! Define path constants
---Declaration of the tool, in this case the TCP is moved 430 mm along wrists z-direction, regular Rapidcode--PERS tooldata slip := [TRUE,[[0,0,430],[1,0,0,0]],[1,[0,0,220],[1,0,0,0],0,0,0]];
---Declaration of the points and their location that is going to be used in the program, regular Rapidcode--CONST robtarget C001 := [[1100,246,1252],[0,0,-1,0],[0,0,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
CONST robtarget C002 := [[1378,484,1252],[0,0,-1,0],[0,0,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
CONST robtarget C003 := [[1378,60,1252],[0,0,-1,0],[0,0,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
---Declaration of the velocities that are going to be used in the program, regular Rapidcode--CONST speeddata spd001 := [100.00,500.00,1203.00,1000.00];
CONST speeddata spd002 := [5.00,500.00,20.00,1000.00];
PROC main ()
---Points to move along when before entering sensorscope, regular Rapidcode --MoveL C001, spd001, z40, slip;
MoveL C002, spd001, z40, slip;
73
New Interface for Rapid Feedback on ABB-robots
---Here starts the extended part of this program-----Decleration of which sensor that is used and which type of sensor that sensor is, as you can se the sensor id is
set to optidrive--!! Enter sensor scope
!<sensor id="optidrive"
!
type="force"
!
interface="LTH S4Cplus Extension">
---Entering forcescope, below is all the variables set to önskade values--!! Enter force scope
---Declaration of in which direction to search, as mentioned earlier in the text it is only possible to use the tools x
direction in the current implementation done at Linköping institute of technology--!<force surfaceSearchDirection="1,0,0"
---Declaration of which speed that is going to be used when searching for surface--!
surfaceSearchSpeed="10mm/s"
---Declaration in which direction the forcecompensation should occur--!
forceDirection="1,0,0"
---Declaration of which function to build force that is going to be used--!
buildForceFunc="upramp"
---Declaration of which time that should be used to build wanted force, always allow some time for build.
!
buildForceTime="100ms"
---Declaration when the force is ready built--!
buildForceFinalValue="20N"
---Declaration when the system should consider that contact is made--!
buildForceContactThreshold="10N"
---Declaration of when the system is allowed to begin the movement that is commanded inside the forcescope-!
buildForceTriggValue="16N"
---Declaration of how long that system should wait until time out occurs when searching for surface--!
74
buildForceTimeout="30s"
Appendix A
ExtRAPID An Example
---Declaration of which function that should be used when realising the pressure--!
retractForceFunc="downramp"
---Declaration of how long time it should take for the force to decrease--!
retractForceTime="1000ms"
---Declaration of when the system has loose contact
!
retractForceNoContactThreshold="5N"
---Declaration of which pressure and function that used be used during the instructions inside the force scope--!
processForceFunc="constant 20N"
---Declaration of which function that is going to be used during the process--!
processVelocityFunc="void">
---Points to move along with constant pressure --MoveL C002, spd002, z40, slip;
MoveL C003, spd002, z40, slip;
---Exiting force scope--!</force>
---Exiting sensor scope--!</sensor>
---Points to move along when sensorscope is exited, regular Rapidcode --MoveL C003, spd001, z40, slip;
MoveL C001, spd001, z40, slip;
ENDPROC
ENDMODULE
75
Appendix B
Appendix B
Running an ExtRAPID program.
Running an ExtRAPID program.
1. Boot MasterPC
2. Boot SensorPC
3. Start Sensor Control on SensorPC and calibrate
4. Start S4Cplus - Automatic mode
5. Start Opcom on MasterPC – make sure G4 boots correctly
6. Set Parameters and start Force control in Opcom
7. Start ExtRAPID with ExtCtrl
8. Start sending force data from Sensor Control
77
Appendix C
Appendix C
ATI F/T Sensor
ATI F/T Sensor
79
New Interface for Rapid Feedback on ABB-robots
80
Appendix D
Appendix D
G4 PowerPC PrPMC800-1261
G4 PowerPC PrPMC800-1261
81
New Interface for Rapid Feedback on ABB-robots
82
Appendix D
G4 PowerPC PrPMC800-1261
83
Appendix E
Appendix E
Advantech PCI-1711
Advantech PCI-1711
85
New Interface for Rapid Feedback on ABB-robots
86
Appendix F
Appendix F
dhcpd.conf
dhcpd.conf
ddns-update-style interim;
ignore client-updates;
allow booting;
allow bootp;
DHCPD_INTERFACE = "eth1";
# The robot shop local network
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.10 192.168.0.90;
default-lease-time 600; max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name "robot.lith";
get-lease-hostnames true;
use-host-decl-names on;
group{
host prpmc3 {
hardware ethernet 00:01:AF:04:B2:3B;
fixed-address 192.168.0.200;
option host-name "prpmc3";
server-name "master.robot.lith";
next-server master.robot.lith;
}
host old
{
hardware ethernet 00:C0:26:C0:3A:9E;
fixed-address 192.168.0.140;
}
host lapis {
hardware ethernet 00:0A:E4:0D:C9:6F;
fixed-address 192.168.0.8;
}
host platon {
hardware ethernet 00:0E:7B:A1:E7:20;
fixed-address 192.168.0.9;
}
host irb
{
hardware ethernet 00:01:AF:07:2C:4A;
fixed-address 192.168.0.100;
}
}
}
87
Appendix G
Appendix G
Stork
Stork
This is the script used for parsing the configuration file for the digital in signals
on the Advantech 1711 card.
#!/usr/bin/perl
if ($ARGV[0] eq "start") {
open(CONFIG, "/etc/stork.conf");
while (<CONFIG>) {
if (/^\s*configure\s+([^0-9]+([0-9]+))\s+(.*)$/) {
$dev = $1;
$minor = $2;
$parameters = $3;
system("/bin/mknod $dev c 98 $minor");
system("chown root.root $dev");
system("chmod 666 $dev");
print("/usr/local/sbin/comedi_config $dev $parameters\n");
system("/usr/local/sbin/comedi_config $dev $parameters");
} elsif (/^\s*modules\s+(.*)$/) {
foreach $module (split(" ", $1)) {
print("/sbin/modprobe $module\n");
system("/sbin/modprobe $module");
}
} elsif (/^\s*din\s+[0-9]+\s+(\S+)\s+([0-9]+)\s*:\s*([0-9]+)\s*$/) {
$dev = $1;
$subdev = $2;
$chan = $3;
print("/usr/local/sbin/comedi_digitalsetup $dev $subdev $chan in\n");
system("/usr/local/sbin/comedi_digitalsetup $dev $subdev $chan in");
} elsif (/^\s*dout\s+[0-9]+\s+(\S+)\s+([0-9]+)\s*:\s*([0-9]+)\s*$/) {
$dev = $1;
$subdev = $2;
$chan = $3;
print("/usr/sbin/comedi_digitalsetup $dev $subdev $chan out\n");
89
New Interface for Rapid Feedback on ABB-robots
system("/usr/sbin/comedi_digitalsetup $dev $subdev $chan out");
}
}
close(CONFIG);
} elsif ($ARGV[0] eq "stop") {
open(CONFIG, "/etc/stork.conf");
while (<CONFIG>) {
if (/^\s*modules\s+(.*)$/) {
foreach $module (reverse(split(" ", $1))) {
print("/sbin/rmmod $module\n");
system("/sbin/rmmod $module");
}
}
}
close(CONFIG);
system("rm /dev/comedi*");
} elsif ($ARGV[0] eq "restart" || $ARGV[0] eq "reload") {
system("$0 stop");
system("$0 start");
} elsif ($ARGV[0] eq "status") {
system("/usr/sbin/comedi_status /dev/comedi0");
system("/usr/sbin/comedi_status /dev/comedi1");
system("/usr/sbin/comedi_status /dev/comedi2");
system("/usr/sbin/comedi_status /dev/comedi3");
}
90
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement