Proceedings of the ASME 2009 International Design Engineering Technical Conferences &

Computers and Information in Engineering Conference

IDETC/CIE 2009
Proceedings of the ASME 2008 International August
Design Engineering Technical
30 - September 2, 2009,Conferences & Computers
San Diego, California, and
USA
Information in Engineering Conference
IDETC/CIE 2009
August 30 - September 2, 2009, San Diego, California, USA

DETC2009-86613
DETC2009-86613

AUTOMATED DESIGN OF AN INDUSTRIAL ROBOT FAMILY

Clemens Mandl Xiaolong Feng
University of Applied Sciences Technikum Wien ABB Corporate Research
A-1200 Vienna SE-721 78 Västerås
Austria Sweden
Johan Ölvander
Linköping University
SE-581 83 Linköping
Sweden

ABSTRACT trade-off between commonality and individually optimized

In this work, a methodology and an integrated tool
framework has been developed for automated design of an
industrial robot family consisting of four robot members. For
each robot, performance requirements concerning payloads,
reaches, and time performances are specified. A 3D design tool,
namely SolidWorks, has been integrated with robot kinematics
and dynamics simulation tools for simultaneous kinematics and
dynamics design. A motor library comprising both geometric
data and physical data has also been integrated in the tool
framework. The automated design of the robot family has been
formulated as a multi-objective and mixed variable design
optimization problem. The arm modules are treated as
continuous design variables while the motors are treated as
discrete variables. Due to the characteristics of this mixed
variable design optimization problem a genetic algorithm (GA)
has been used. This work has successfully demonstrated the
feasibility for achieving automatic design of an industrial robot
family.
INTRODUCTION
Increasing competition on a global market place has
resulted in the general trend and practice to develop and
introduce product families, instead of individual products. This
leads to increased product variants to satisfy better customers’
need, and shortened time-to-market per product for
manufacturers.
A product family is represented by a number of variant
products sharing a common platform. The platform typically
consists of a set of components, modules, or manufacturing and
assembly processes. Product family design can reduce cost due
to the commonality between the variants, but there is always a
performance [1], [2]. One question for evaluating the efficiency
of a common platform is therefore: How severe is this trade-off
or compromise for each of the family members? Hence a
balance between decreased overall product cost and decrease of
performance of individual members has to be found.
The design of a product family has been the subject of
research for several years, and many approaches have been
presented for various product domains, for a survey of different
methods, see [3] and [4]. According to [5] the major tasks can
be summarized as:
I. Design of the platform for a specified family.
II. Design of the family based on a specified platform.
III. Simultaneous design of both platform and family.
The above design tasks typically result in a combinatorial
optimization problem including both continuous and discrete
optimization variables.
In the literature there are many approaches targeting the
different problem types outlined above, see [3] and [4] and the
references therein. Depending on the problem type and the
application studied different optimization methods might be
appropriate. In this paper a Genetic Algorithms is used as has
been used as it can effectively handled problems with mixed
continuous and discrete variables and are able to find global
optima in multi-modal search spaces. In the area of product
family optimization, genetic algorithms in general and multi-
objective GA (MOGA) in particular have been commonly used
- see [5], [6], [7].
In robotics industry, it has been an increasing practice to
develop and introduce a group of robots, or a robot family, at
the same time. In this practice, the robot members in the family

1 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use

 are normally created by using different lower and upper arms
and sharing as much as possible of other components, like
drive-train components (motors and gearboxes) or other
structural components, cabling systems, etc.
However, the design of industrial robots is a very complex
process requiring numerous design iterations among kinematics
design, dynamics design, drive-train dimensioning, structure
design, thermal design, and stiffness design. This in turn
requires usage of software tools spanning several engineering
domains, from 3D CAD modeling tools for geometric robot
design, robot motion simulation tools for robot performance
simulation and drive-train sizing, to finite element analysis
(FEA) for structural stress analysis, thermal analysis, and
stiffness analysis [8], [9]. Design of a robot family poses even
higher demands requiring simultaneous design of all robot
members in the family while taking into account the component
sharing strategy among them. However, successfully achieving
automatic and optimal design of an industrial robot family
causes the following technology challenges:
• How can an industrial robot be constructed in a way
that its structural components may be parameterized
effectively and how can the parameterized
components be changed outside of a 3D design tool
in an optimization loop?
• How can new mass properties of a robot be
automatically extracted and exported to a robot data
file (RDF) when the geometry of some robot
components has been changed?
• How can kinematic simulations for predicting the
shape of the workspace and for relocating a robot
motion cycle in the workspace of a robot be
conducted automatically in an optimization loop?
This is essential since different robot members in the
family usually have different lower and/or upper arm
lengths and therefore different reaches of their tool
center points.
• How can an integrated tool framework for
optimization be developed to integrate geometric and
kinematic simulations with robot motion simulation
tools, including data transfer among the tools?
• How can automatic design of a robot family be
formulated as a multi-objective optimization
problem and how can this problem be solved in an
efficient way?
• How can the component sharing issues be
automatically treated in the optimization loop?
Furthermore, automatic and optimal design of an industrial
robot family is a necessary step towards platform-based
industrial robot development. The platform-based robot
development implies the development of structural modules,
drive-train modules consisting of gearboxes and motors, and
other supplementary equipments like cabling systems, and
assemblies for measurement boards, based on which a number
of robot families can be effectively developed. The subject of
more sophisticated platform-based industrial robot
development will be addressed in future publications. In this
work, this research topic has been limited to determine an
optimum module platform consisting only of lower arm
structural modules, upper arm structural modules, and electric
motor modules for one robot family. This family consists of
four robots under condition that an initial design of one robot in
the family is given, i.e. problem II above. This simplified
platform design task should answer the following questions:
• How many different structural modules (i.e. lower
arms and upper arms) are required minimally by the
family to meet the requirements for each of its
members?
• How should these structural modules be designed
(e.g. length of the arms)?
• How should the sharing strategy between the
different robots look like?
• How many different motors are required minimally
to meet the requirements for all family members?
• Which motors (from a pre-defined motor library)
should be used?
• Among which family members and among which
axes should these motors be shared?
The goal of solving this simplified optimum module
platform design problem is to develop the robot family using as
few structural modules and motors as possible while ensuring
that the requirement for each individual robot is fulfilled. The
problem formulation is further explained in Figure 1.
Figure 1: Problem formulation of this work
This work is an extension of previous work published by
Ölvander et al. [10], where optimum kinematics design of an
industrial robot family is studied. Furthermore, a framework for
industrial robot optimization combining geometric CAD
models (using CATIA V5) and dynamic simulations (using
Dymola) is presented in [11]. However the product family
design problem is not addressed. Otherwise, due to the

2 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use

 complexity of industrial robot design, to our knowledge, no the robot workspace. This requires the integration of the robot
previous attempts in challenging automatic design of an kinematics simulation tool into the robot simulation tool
industrial robot family have been widely discussed and framework and re-programming of the target positions of the
disclosed in academia. robot motion cycle.
This paper is structured in following sections: Section
1) Re-computation of the shape of the workspace and
Methods details the development in the parameterization of the
control if the stroke of the workspace would fulfill the
3D robot model and the tool framework for integration of the
constraint to this quantity. The stroke is defined as the
design and simulation tools. The Optimization section describes
offset between maximum reach and minimum reach of
the problem formulation and the solution approach. Thereafter
the WCP of a robot (see Figure 2). This definition
the results are presented, and eventually conclusions and future
emphasizes not only the maximum reach, obviously
work are given in the last section.
the most significant kinematics performance measure,
but also how close the robot can work in vicinity of its
METHODS
base. This in turn promotes more the importance of
Automated design of a family of industrial robots has been
shape of the robot workspace. The relative stroke is
formulated as a design optimization problem and solved by
the stroke of a robot divided by the maximum stroke
optimization.
(while ensuring the same reach), obtained when lower
The design variable vector contains the lengths of lower
and upper arms have the same length. Both the stroke
and upper arms and the motor index for each axis of all robots
and the relative stroke are calculated numerically
in the family. Arm lengths are treated as continuous variables
based on the length of the upper and lower arms of a
and motors are chosen from a motor library represented by
robot and the arm rotational angle limits using the
integer variables. This implies a mixed variable type of
kinematic model developed in MATLAB.
optimization problem. A genetic algorithm (GA) type
optimizer, available in MATLAB, is used in this work to handle
this mixed variable optimization problem. The formulation of
objective function and constraints will be detailed in the
optimization section. Furthermore, the tool framework for robot
system simulation and work flow for robot design optimization
will be detailed below.
Solving this type of optimization problem requires the
development of a common simulation tool framework
comprising integration of a
1) robot kinematics simulation tool
2) a robot 3D modeling tool
3) a robot dynamic simulation tool, and a
4) motor library
These robot simulation tools cooperate with MATLAB to
form a holistic tool framework which enables automated Figure 2: Shape of workspace and definition of stroke
design.
The kinematic model is developed directly in MATLAB. 2) The optimization is mainly based on robot
SolidWorks is used as the 3D modeling tool, and is integrated performance measured on a robot motion cycle. In this
into the tool framework with help of MS Visual Basic and work, a typical robot design cycle is used. This robot
SolidWorks-API [12]. The robot dynamic simulation tool used cycle consists of 9 position targets: 8 position targets
is an ABB robot motion simulator, which is integrated in defining corner points of a rectangular cube with
MATLAB. dimension of 800 x 800 x 700 mm and position P1
A typical iteration in the optimization loop requires the which is the center point or reference point of the
following robot simulation steps: cube. When position of P1 is changed, positions of all
8 corner points of the rectangular cube will be
• Robot kinematics simulation
changed correspondingly. The robot tool center point
• Manipulation of robot geometry
(TCP) starts at P1 and visits one of the 8 corner points,
• Robot dynamic simulation returns to P1 and visits the next corner point, etc.,
until the TCP has visited all 8 corner points, returns
Robot kinematics simulation and stops at P1. Moreover, the payload is defined in
A change of the length of lower and/or upper arms requires the robot cycle and is adapted based on the specified
1) re-computing the shape of robot workspace and 2) re- required payload for each member in the product
positioning the robot motion cycle to appropriate positions in

3 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use

 family. The cycle position needs to be adjusted,
making sure that the cycle is re-located to the
workspace center point (WSC, see Figure 2) for each
optimization loop when the length of any robot arms
has been changed.
Figure 3: Graphical illustration of the
robot design cycle
Manipulation of the robot geometry
A change of the length of lower and/or upper arms also
requires a change of the geometry in the 3D CAD model in
order to export new mass data into the Robot Data File (RDF)
for performing dynamic robot simulations. This requires the
integration of the 3D CAD tool into the robot simulation tool
framework - so that the change in robot geometry can be
conducted outside the 3D CAD modeling tool within the
optimization loop. In this work, SolidWorks is used as the 3D
modeling tool. The lower and upper arms are fully
parameterized, e.g. for the change in lengths. Figure 4 shows a
parameterization example of a set of lower arms with three
different arm lengths.
Figure 4: Parameterization example: lower arms
The change of a motor in the optimization loop requires
two-step actions:
1) Load the new motor geometry into the 3D CAD model to
represent a motor change, access the new mass data of the
4 Copyright © 2009 by ASME
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use
appropriate robot assembly associated to the motor and import
the mass data into the RDF for robot dynamic simulation.
2) Load physical parameters of the motor into the RDF for
robot dynamic simulations. This requires the integration of the
motor library into the robot simulation tool framework.
Robot dynamic simulation
The robot dynamic simulation tool used in this work is an
ABB robot motion simulator, adapted from ABB’s offline
simulation tool RobotStudio. The ABB motion simulator is
integrated in the tool framework through a COM object
provided in MATLAB. Robot dynamic performance is
simulated, predicted, and used to compute the dynamic
performance for different designs.
Single robot optimization
Work flow and tool framework for single robot optimization is
detailed in Figure 5.
Figure 5: Work flow and tool framework
for single robot optimization
The major steps in the work flow are given below:
1) The optimization algorithm inside MATLAB suggests the
design variable values.
2) Design variables defining arm lengths are transferred to
SolidWorks to manipulate the robot 3D model. The joint
distances are calculated and used as input for a workspace
calculation. Furthermore, the joint distances also need to be
imported into the RDF for performing robot dynamic
performance simulations.
3) The workspace calculation provides the reach and the
stroke used for evaluating the performance part of the
objective function.
4) Through step 2), after manipulation of the robot 3D CAD
model, the mass data is extracted and imported into the
RDF for the dynamic robot performance simulations.
5) The MATLAB program “physical adaptation” is called to
adapt the parameters in the RDF, which do not need data
from the CAD model (for example the used motors or
required motor torques).
 6) The new RDF is readily prepared and can be used to
perform a dynamic robot simulation. The robot motion
simulator loads the new RDF and the adjusted duty cycle to
simulate and predict the dynamic performance of the robot.
The position of the cycle has been adapted according to the
WSC of the new workspace.
7) Finally, the results of the robot dynamic simulation (for
example cycle time, gear lifetime, and structural forces) is
used for evaluating the performance part of the objective
function.
The time per simulation loop depends on the number of
involved CAD sections, the number of used robot cycles, and
the time to simulate each robot cycle. As an example: To
simulate one robot involving four CAD sections and one
motion cycle with 10 seconds simulation time takes about 70
seconds on a desktop PC with 1.86Ghz AMD processor and
2GB of RAM.
Multiple robot optimization
Optimizing multiple robots in the same optimization loop
requires formulation of an overall objective function
considering not only performance requirements but also the
module sharing strategy. The module sharing strategy is
formulated as a penalty in the objective function and needs to
be calculated at the beginning of every iteration. Another
challenge is to handle data, manipulate geometry, and simulate
kinematics and dynamic performance of multiple robots in the
same optimization loop.
OPTIMIZATION
Within this section the optimization problem will be
outlined starting with a description of the optimization
variables, followed by the problem formulation and eventually
the optimization algorithm.
Design variables
Referring to a simple example with four robots, the two
modules lower arm and upper arm and the motors for axes 1 to
3 (only main axes of the robots), the following 20 design
variables are needed.
This formulation is based on:
5 Copyright © 2009 by ASME
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use
• real numbers representing scaling factors to scale the
structural modules (to change e.g. the original arm
lengths) and
• integers representing the index of the chosen motor
in a library (dynamic model as well as CAD model).
This leads to a mixed variable design optimization problem,
where the design vector, x=[x1,x2,..,x20], contains 8 real
numbers and 12 integers.
Objective function formulation
The design measures are the cycles or robot programs used
to perform the motion simulations. The number of cycles which
can be used in the optimization is theoretically unlimited – but
the time per optimization loop increases.
The development of a mathematical formulation
determining the fitness of a module platform is one of the most
demanding parts of modular robot family design. The main
challenge is that this problem consists generally of two goals
that are more or less the opposite of each other. The first goal is
the highest possible modularity (to share as many structural
modules and motors as possible) and the second goal is to meet
the performance requirements for each of the family members/
robots. These opposite goals are so to speak cost effectiveness
versus performance.
The objective of the optimization is to find the minimum
possible number of modules with the constraint that the
specified performance requirements are met for all family
members. Due to these problem characteristics, the modularity
is formulated as objective, mod_obj, and the performances as
penalty, perf_pen.
The commonality measure used (mod_obj) is tailored to
reflect the commonality within a family of industrial robots. An
alternative approach would be to use one of the commonality
indices that could be found in the literature, see, [13] and [14].
This is however an area for future work.
The fitness value, f, for a specific module platform, mp, is
calculated by summing mod_obj and perf_pen times their
weighing factors αmod and αperf. By use of these factors, the
importance of modularity and performance can be considered
in the objective function, see equation (1).
min f ( x ) = α mod ⋅ mod _ obj ( x ) + α perf ⋅ perf _ pen ( x ) (1)
The underlying equations describing the modularity
objective and performance penalty will now be described in a
top-down fashion.
Modularity objective
The modularity objective consists of two parts: One
regarding structural modules and another regarding motors (as
given in the equation below).
mod _ obj ( x ) =mod _ struct ( x ) + mod _ motor ( x ) (2)
The main reason why they have to be split up is their
different sharing opportunities among the robot family. (In a
 serial arranged 6-axis kinematic, there are 7 robot links or
structural modules. The joints are placed between all adjacent
links.) Structural modules are considered as modules which can
only be shared with the same link type. For example – link 3 is
the lower arm in a serial kinematic and can only be used as
lower arm and therefore also only be shared with the lower arm
of another robot in the family.
Motors, on the other hand, are considered as modules
which can also be shared among different axis – e.g. the motor
of axis 2 can also be used as motor for axis 3 (in another robot
of the family and even within the same robot).
The structural modularity will now be explained (the
formulation of the motor modularity works comparably). For
each robot family the possible number of structural components
(defining the module platform) has the following theoretical
range:
mod_struct ( x ) = nm ( x ) ⋅ dm ( x ) (3)
The structural modularity factor nm(x) depends on the
current number of shared components, nComp(x).
(x) ⎞
2
⎛n
nm ( x ) = ⎜ Comp ⎟⎟ (4)
⎜ n
⎝ min Comp ⎠
The number of shared components is calculated based on
the assumption that it is considered possible to share a common
component if the difference between two modules is less than
5%. In this work, the module sharing criterion of 5% is
obtained by the engineering practice. No sensitivity study was
conducted that supports this criterion. This criterion will be
quantified based on methodology proposed in [1] in the future.
But if only the number of shared modules were used as
modularity measure, it would not be considered how much the
design of unshared components differs from each other – if
their design is too different to be shared or if they could almost
be shared. To encourage the trend towards another shared
component dm(x) has been introduced.
The number of possible combinations among the defined
robots for each structural module is:

nrob ⋅ (nrob − 1)
nstructCombo = (5)
2
In a family with four robots, this number would be 6 (see
nmod marks the number of considered robot modules, e.g. if Table 1). For each of these combinations, the
only upper and lower arms are considered in an optimization difference between the modules is calculated. For example – if
nmod would be 2. nminComp is the minimum value bound or the the scaling factor defining the lower arm of Robot 1 is 1.10 and
minimal number of components in the module platform. For the scaling factor defining the lower arm of robot 2 is 0.95 –
example, in case of a robot family with 4 members and with their difference is 0.15.
nmod=2, nminComp would be 4, because in a structural module
platform with only 3 components at least two robots of the Table 1: Structural differences
family would have the same kinematics design. Module 1 Module 2
The maximum value bound of nmax_strucComp presented Lower Arm Upper Arm
above can be set for reducing the optimization time, in Combo 1: R1-R2 0.15 0.55
particular for eliminating unnecessary calls of dynamic Combo 2: R1-R3 0.7 0.04
simulation which is most time consuming. In the optimization, Combo 3: R1-R4 0.07 0.2
family designs with more structural components than Combo 4: R2-R3 0.1 0.6
nmax_strucComp or less than nminComp are simply not considered (see Combo 5: R2-R4 0.64 0.001
chapter “simulation time reduction” below and Figure 7). In Combo 6: R3-R4 0.02 0.43
principle, the overall objective function and the optimizer All differences which are less than 0.05 (or 5%) are
proposes the optimal module sharing strategy with the optimal considered as shared components, which means in case of this
number of modules between nminComp and nmax_strucComp. example that:
Investigations to quantify how this influences the optimization
time, in particular the number of iterations with dynamic • Robot 3 and 4 can share the same lower arm
simulations, are given in Figure 8 and Figure 9. • Robot 2 and 4 can share the same upper arm and
The modularity objective contains two factors. The first • Robot 1 and 3 can share another upper arm
factor emphasizes the number of shared modules (nm(x)), Since the best possible family design for this example is to
whereas the second factor addresses the difference between the have a structural module platform with 4 components, only 4
modules within the platform, (dm(x)), see equation (3). components can be saved compared to individual robot design.
Due to that, it is not necessary to consider all the differences

6 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use

 from the table above. Only a number of the smallest differences
need to be considered and this is the number of components
that can be saved in the best case (see equation below).
(6)
In case of this example, only the 4 smallest differences
Specific design variable combinations for one module
between two different robots (illustrated by the black points)
are pushed towards the blue line, where the modules are equal.
Within 5% tolerance around this exact equality line, illustrated
by the red lines, the component is considered as shared.
Performance penalty
The term perf_pen defined in equation (1) may be detailed
using equation (8) below.
nrob

need to be considered. 3 of them could already be considered as ∑ (TP + WS

i i
reach
+ WSi stroke + OSi + GLi )
shared components, as only the difference of one of the perf _ pen = i =1 (8)
possible four saved components is higher than 5%. This nrob
combination is considered as a possibly shared component
perf_pen delivers the average performance of all robots
(lower arm between robot 1 and 4). However, the difference
defined in the family. It considers the following significant
has to be reduced by the optimization.
values, which are all calculated based on a set of representative
Finally, the difference between the modules for a module
duty cycles.
platform can be calculated according to equation (7),
• Time performance of robot i, TPi .
nsavedComp _ best

∑ Diffi ( x )
dm ( x ) = i =1
(7)
nsavedComp _ best
where Diff(x) are the differences between the modules sorted in
ascending order. For the example above equation (7) would
equal (0.001+0.02+0.04+0.07)/4=0.033.
The minimization of this formulation provokes a push of
the design variables belonging to the same module of different
robots towards each other (to cause a shared component). In
Figure 6 a graphical explanation of this formulation, with 3
different designs (small circles), is provided (x-axis: scaling
factor of the lower arm of robot 1, y-axis: scaling factor of the
lower arm of robot 2).
• Workspace reach for robot i, WSi reach .
• Workspace stroke for robot i ( WSi stroke )
• Overstraining of robot i, OSi
• Gear lifetime for robot i ( GLi )
The penalty formulation works similarly for all of these
performance related values: If the current performance is worse
than its requirement a penalty is calculated (dependent on the
difference between current and required performance). All
constraints, except for workspace reach, which is an equality
constraint, are formulated using negative null form, i.e.
g j ( x ) ≤ 0 , and the penalty is calculated as pen = max ( 0, g j ( x ) ) .
2
As an example, the time performance penalty TPi will be
explained.
The time performance for the current robot configuration is
the average cycle time for all cycles, which needs to be smaller
than the specified requirement, CTreq.
ncycles

∑ CT n
g1 ( x ) = n =1
− CTreq ≤ 0 (9)
ncycles
The time performance penalty for robot i is thus formulated as:

TPi = max ( 0, g1 ( x ) ) , i = 1,..., 4

2
(10)

The penalty for the workspace reach ( WSi reach ) works

differently as it is an equality constraint. For each member in
the family the reach Ri should equal the required reach for that
particular individual.

Figure 6: Structural modularity – difference example

7 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use

 g 2 ( x ) = Ri − Rirequired = 0
WSireach = ( g 2 ( x ) ) , i = 1,...4
2 (11)
Moreover, the overstraining penalty ( OSi ) needs to be
explained. This penalty is introduced in order to keep the
structural loads and torques under control, i.e. if a specific
structural load for a specific robot configuration becomes
higher than its critical valid load, it violates the overstraining
constraint. For future work a finite element analysis (FEA) will
be included in the optimization loop instead.
Finally, it has to be mentioned that the payload is not
directly included as a performance penalty – it is used in the
specified cycles and thereby affects the penalties TPi , OSi and
GLi indirectly.
beginning of every iteration of the optimization algorithm. This
determination does not take much calculation time compared
with the determination of the (missing) performance penalties
time performance, gear lifetime, and structural forces, because
only for them cycle simulations have to be performed.
To handle this vast solution space in the fastest possible
way, the number of dynamic simulations should be kept as low
as possible in order to minimize the total optimization time.
That is done by requesting a specified minimum fitness of the
modularity and the workspace (see Figure 7).

Algorithm
Robot design optimization (especially robot family design
optimization) is a multi-objective and multi-constraint
optimization problem with the following characteristics:
Figure 7: Sub-loop
• Discontinuous (objective function formulation)
If their fitness is not good enough, no cycle simulations are
• Multiple (local) minima/ optima
performed. But in these cases, a penalty factor has to be added
• Complex (little knowledge about solutions)
to substitute the missing cycle-based performance penalties and
These characteristics limit the algorithms that can be make sure that the overall fitness of the invalid individual is
chosen significantly. The most suitable optimization method for one level higher than the overall fitness of the valid individuals.
this problem is the genetic algorithm. In the Figure 8, all individuals of an optimization over 45
This algorithm is based on the mechanics of natural generations are plotted. The vertical lines mark the borders
selection or evolution. According to [15] each optimization between the generations. The individuals represented by blue
parameter symbolizes a gene. The corresponding genes of all circles illustrate invalid solutions with bad fitness values while
parameters form a chromosome or system DNA, which the individuals in red stars illustrate valid solutions.
describes each individual. Each individual represents a possible
solution, and a set of individuals form a population. Within a
population, the fittest individuals are favored for mating, which
is performed by combining the genes from different individuals
(parents) to produce a new individual (child) by the use of
operators borrowed from natural genetics. These children are
then inserted into the population and become a new generation
(replacing their parents) and with every new generation, better
approximations to an optimal solution are produced [16].
Genetic algorithms are more robust, which means for
example that they can handle discontinuous objective function
formulations. They are capable of searching the solution space
with more likelihood of finding the global optimum. Genetic
algorithms are globally oriented and generally more
straightforward to apply in situations where there is little or no
a priori knowledge about the problem to solve, because only
the objective function and corresponding fitness levels
influence the directions of search using probabilistic transition
rules. Figure 8: Individual fitness - valid/ invalid iterations
Simulation time reduction Obviously, the used genetic algorithm is robust enough to
The modularity fitness and the performance penalties handle this kind of formulation and it saves an enormous
workspace reach and workspace stroke are determined in the amount of simulation time. In this example, only 915 of 1913

8 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use

 iterations have been valid (more than 52% optimization time
reduction). Moreover, the number of valid iterations should
increase with the number of generations, which is easier to see
in Figure 9. Furthermore, this figure also shows the
convergence of the genetic algorithm, both in terms of the best
individual obtained and the average of the population.
Figure 9: Convergence curves and number of valid iterations
RESULTS
The proposed and developed methodology and tools are
used for optimal and automatic design of an industrial robot
family comprising 4 robots. Results of the robot family design
are detailed in this section.
Requirements
The requirement specifications of the four robots are given
in Table 2.
Table 2: Requirement specifications (maximum reach and
payload)
All other performance requirements are equal for all family
members/ robots:
• Required cycle time:
maximum 11 seconds for executing the robot design
cycle
• Required relative stroke:
Minimum allowed stroke = 62%
Two levels of modular design commonality have been
investigated. The low modular commonality case (Solution A)
9 Copyright © 2009 by ASME
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use
allows maximal five arm modules and four motors for creating
the robot family, while the high modular commonality case
(Solution B) allows maximal four arm modules and three
motors.
Robot family solution A (with low modular commonality)
Structural design
Following 5 structural modules are proposed by the
optimization: 2 lower arms and 3 upper arms. Their designs (or
lengths) are detailed in Table 3.
Table 3: Family solution A – optimized arm modules
The structural sharing strategy proposed by optimization is
outlined in Figure 10.
Figure 10: Family solution A - structural sharing strategy
This means the optimization suggested the following arm
module sharing strategy:
• Robot 1 and robot 2 share lower arm number 1
• Robot 3 and robot 4 share lower arm number 2
• Robot 2 and robot 4 share upper arm number 3
Drive train design
Four motors have been chosen by the optimization for the
three main axes of the four robots in the robot family. The
optimum motor sharing strategy proposed by optimization is
tabulated below.
Table 4: Family solution A – optimized motor modules
In the table, Mx is the index used in the motor library. Table 4
indicates the following motor sharing strategy:
• Motor M5 is shared by 5 axes in the robot family
• Motor M3 is shared by 3 axes in the robot family
• Motor M2 is shared by 2 axes in the robot family
• Motor M4 is shared by 2 axes in the robot family
 Performance
The major performance values for all 4 robots in the family are
tabulated in Table 5, while the structural forces and gear
lifetimes are under control. In this table, when the actual
performance can not meet its requirement, the relative
deviation between actual and required performance (cycle time,
reach, and stroke) is also presented. The performance penalty
calculation used in the optimization is based on these
deviations. The result presented in the table indicates that only
the required cycle time and relative stroke of robot 2 has not
been met.
Table 5: Family solution A - required vs. optimized
performances
Robot family solution B (with high modular commonality)
Structural design
Following 4 structural modules are proposed by the
optimization: 2 lower arms and 2 upper arms. Their designs (or
lengths) are detailed in Table 6.
Table 6: Family solution B – optimized arm modules
The structural sharing strategy proposed by optimization is
outlined in Figure 11.
Figure 11: Family solution B - structural sharing strategy
Which means the optimization suggested the following arm
module sharing strategy:
• Robot 1 and robot 2 share lower arm number 1
• Robot 3 and robot 4 share lower arm number 2
• Robot 1 and robot 3 share upper arm number 1
• Robot 2 and robot 4 share upper arm number 2
Drive train design
Three motors have been chosen by the optimization for the
three main axes of the four robots in the robot family. The
optimum motor sharing strategy proposed by optimization is
tabulated below.
10
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use
Table 7: Family solution B – optimized motor modules
In the table, Mx is the index used in the motor library.
Table 7 indicates the following motor sharing strategy:
• Motor M4 is shared by 5 axes in the robot family
• Motor M3 is shared by 5 axes in the robot family
• Motor M2 is shared by 2 axes in the robot family
Performance
The major performance values for all 4 robots in the family are
tabulated in Table 8, while the structural forces and gear
lifetimes are under control. In this table, when the actual
performance can not meet its requirement, the relative
deviation between actual and required performance (cycle time,
reach, and stroke) is also presented. The performance penalty
calculation used in the optimization is based on these
deviations. The result presented in the table indicates that for
robots 1 and 2, the required cycle time and relative stroke have
not been met, since the reach is too long. In contrast to robots 3
and 4, where the reach is too short and therewith the other
requirements over-fulfilled. The conclusion is that the high
modularity in the solution B has sacrificed the performance
requirement for all robots in either cycle time, reach, or stroke.
Table 8: Family solution B – required vs. optimized
performances
Benchmark between solutions A and B
In Figure 12, the performance penalties of solution A presented
in Table 5 and solution B listed in Table 8 are compared. It is
evident that both workspace reach and stroke penalties of
solution B are comparably high. In addition, it is possible to see
that the overall performance penalty of solution B is more than
twice as high than the overall performance penalty of solution
A. This supports the conclusion that the higher scarification of
the performance in solution B results from a higher degree of
modularity.
Copyright © 2009 by ASME

Figure 13: Performance penalty comparison
Trade-off analysis (commonality vs. performance)
A possible drawback of robot family design is that the
performances of individual robots are compromised due to the
constraints added by the common platform, i.e. components
need to be shared by other family members.
To evaluate this performance compromise caused by the
higher degree of commonality, each robot in the family resulted
from the design optimization of the robot family is compared
with its associated individual optimized robot (without
consideration of a common platform). The individual robot
optimization can be performed easily using the developed tool
framework. In an individual robot optimization, no module
share is considered. Instead, the objective is to simply find the
optimum design when the performance requirements on the
cycle time and stroke are maximized while the required reach is
fulfilled.
The trade-off of component modules for solution A for all
the 4 robots is given in Table 9. As discussed previously, the 4
robots designed using module sharing solution A use only 5
different arm modules, while the individually optimized 4
robots use 8 different arm modules.
Table 9: Trade-off of component modules for robot family
using module sharing solution A
11
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use
The trade-off of performance for the all 4 robots in the
robot family using component sharing solution A is given in
Table 10. For all the 4 robots in the family, the individually
optimized robot achieves exact requirement on the robot reach,
while the cycle time and the stroke of the robot workspace of
the individually optimized robot are better than those that are
optimized using module sharing solution A. In particular the
cycle time advantage between 5% (robots 1) and 16% (robot 2)
may be achieved for the individually optimized robots. This
advantage in cycle time is rather significant in the practice of
industrial robotics. One main reason for the 16% difference
between the individual and the family design of robot 2 is that
the reach of the family solution is 3% higher than the
requirement (see Table 5). Unfortunately, a realistic cost model
representing the benefit of module sharing is not available in
this work. Such cost model is under development and will be
used in the extension of this work in the future.
Table 10: Trade-off of performance for the robot family
using module sharing solution A
The trade-off of component modules for solution B for all
the 4 robots is given in Table 11. As discussed previously, the 4
robots designed using module sharing solution B use only 4
different arm modules and 3 different motors, while the
individually optimized 4 robots use 8 different arm modules
and also 4 different motors.
Table 11: Trade-off of component modules for robot family
using module sharing solution B
Copyright © 2009 by ASME
 The trade-off of performance for the all 4 robots in the
robot family using component sharing solution B is given in
Table 12. For all the 4 robots in the family, the individually
optimized robot achieves exact requirement on the robot reach,
while the cycle time and the stroke of the robot workspace of
the individually optimized robot are better than those that are
optimized using module sharing solution B. Robot 4 is an
exception, since its cycle time from family solution B is shorter
than the individually optimized robot. This is a result of the
family robot’s reach which is 2.8% shorter than required (see
Table 8). In addition, none of the 4 robots optimized using
module sharing solution B has achieved the exact required
reaches. The reaches of robots 1 and 2 are longer than required
ones while the reaches of robots 3 and 4 are shorter.
Table 12: Trade-off of performance for the robot family
using module sharing solution B
The research experience obtained in this work has
identified limitations of the proposed methodology and
explored new research needs.
DISCUSSION AND CONCLUSIONS
This paper describes first efforts in the research area
module based robot family design. To our best knowledge, this
type of research has not yet been intensively conducted and
disclosed.
Two case studies with different modular commonality
levels have successfully verified the developed methodology
for automatic design of an industrial robot family with
acceptable accuracy using design optimization.
The results presented in this paper have demonstrated
clearly the strength of the developed methodology and tools for
automatic and optimal design of a robot family. Without this
type of methodology and tools, significant efforts are needed
when optimizing all robots in the family individually. This
limits in practice the possibilities concerning study of module
sharing strategies.
The following technologies developed in this work are
essential for successful development of methodology and tools
for automatic design of robot family:
• Integrated design: Realized integration of a CAD
tool in the robot simulation environment.
12
Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use
• Component-based design: A discrete motor library
and parameterized structural components have been
integrated in the robot design and simulation loop.
• Framework of tool chain for design optimization:
Development of module-based optimum design
methodology and tool framework for robot family
design optimization, where multiple robots are
optimized simultaneously based on their module
sharing strategy and performance requirements.
• Overall objective function formulation: Formulation
of an overall objective function considering not only
performance of all family members but also the
fitness of the underlying module platform.
Furthermore, the proposed modularity objective
contains not only the degree of commonality but also
the similarity between modules which promotes the
creation of shared components.
• Verified optimizer: Demonstrated that this type of
problem can be solved using a genetic algorithm.
• A principal limitation of the developed methodology
is how to handle multiple robot programs for each
robot family member, since position of the
programmed robot tool center point targets defined in
the multiple robot programs need to be re-positioned
when the arm lengths are optimized. Both simulating
multiple robot programs and re-positioning of them
will increase the simulation time for each iteration
drastically.
• An obvious extension work is to include a gearbox
library, so that gearboxes can also be optimized. This
requires the development of the gearbox library and
integration of it in the developed tool framework in
the same way as it has been accomplished for motors.
• Another extension of this work could be to include a
cost function for quantifying the benefit of the
module shares. Furthermore, the commonality
measure used in this paper should be benchmarked
against existing commonality indices.
• Significant motion cycles need to be designed,
evaluated and identified as design measures for the
optimization. According to [17] the efficiency of an
optimization is dependent on the significance of its
simulations. The results are only as accurate as the
significance of the used design cycles.
• The parameterization of CAD robot models can be
extended in several ways to automatically manipulate
other structural components like robot base, stand,
and balancing cylinder, etc.
Copyright © 2009 by ASME
 • An essential extension is to include a finite element [10] Ölvander J., Feng X., and Holmgren B., “Optimal
analysis tool in order to be able to calculate the Kinematics Design of an Industrial Robot Family”, in
structural stress, based on the structural forces and the Proceedings of the ASME 2008 International Design
geometric design, and to use it as a constraint in the Engineering Technical Conferences, (DETC2008-
optimization. 49645), 2008.
[11] Tarkian M., Ölvander J., Lundén B., Integration of
ACKNOWLEDGMENTS Parametric CAD and Dynamic Models for Industrial
The first author whishes to express his gratitude to M.Sc. Robot Design and Optimization, ASME Design
Johan Gunnar for essential discussions and ideas concerning Automation Conference, New York, August 3-6, 2008
robot concept design; to Bo Holmgren for providing with a [12] SolidWorks Corporation, 2007. API-Help. Providence:
MATLAB program for workspace calculations; to M.Sc. Hans SolidWorks.
Andersson for help concerning robot motion simulations; to [13] Khajavirad, A. and Michalek, J., An Extension of the
M.Sc. Arne Trangärd for SolidWorks related explanations (all Commonality Index for Product Family Optimization,
at ABB Corporate Research); and to M.Sc. Mehdi Tarkian at ASME Design Engineering Technical Conferences -
Linköping University for demonstrating state-of-the-art in Design Automation Conference, Las Vegas, NV,
CAD model parameterization in CATIA. DETC2007/DAC-35605, 2007.
[14] Thevenot H., Simpson T., Commonality indices for
REFERENCES product family design: a detailed comparison, Journal of
[1] Fellini R., Kokoloras M., Papalambros P., Perez-Duarte Engineering Design, Vol. 17, No. 2, pp 99–119, 2006.
A., “Platform Selection Under Performance Bounds in [15] Goldberg, D., 1989. Genetic Algorithms in Search,
Optimal Design of Product Families”, Journal of Optimization and Machine Learning. Addison Wesley
Mechanical Design, vol. 127, pp. 524-535, July, 2005 [16] Mehnen, L., 2006. Artificial intelligence: informed
[2] Nelson, S., Parkinson M., Papalambros P., “Multicriteria search.
Optimization in Product Platform Design”, Journal of [17] Katalinic, B., 1990. Industrieroboter und flexible
Mechanical Design, vol. 123, pp 199-204, June 2001. Fertigungssysteme für Drehteile. 1. Auflage. Düsseldorf:
[3] Jose A. and Tollenaere M., “Modular and platform VDI Verlag.
methods for product family design: literature analysis”,
Journal of Intelligent Manufacturing, 16, pp. 371-390,
2005.
[4] Simpson, T. W., Product Platform Design and
Optimization: Status and Promise, ASME Design
Engineering Technical Conferences - Design
Automation Conference, Chicago, IL, Paper No.
DETC2003/DAC-48717, 2003.
[5] Fujita K., Yoshida H., “Product Variety Optimization
Simultaneously Designing Module Combination and
Module Attributes”, Concurrent Engineering: Research
and Applications, vol. 12, nr2, June 2004.
[6] Jiao J., Zhang Y., Wang Y., A Generic Genetic Algorithm
for product family design, Journal of Intelligent
Manufacturing, 2007.
[7] Simpson T., D’Souza B., Assessing Variable Levels of
Platform Commonality within a Product Family Using a
Multiobjective Genetic Algorithm, Concurrent
Engineering: Research and Applications, 12(2) pp 199-
129, 2004.
[8] Saitou, K., Izui, K., Nishiwaki, S. and Paplalambros P.,
2005. A Survey of Structural Optimization in
Mechanical Product Development. Providence –
University of Michigan: Department of Mechanical
Engineering.
[9] Shannon R.E., 1975. Systems Simulation: the art and
science. Prentice-Hall.

13 Copyright © 2009 by ASME

Downloaded From: http://proceedings.asmedigitalcollection.asme.org/ on 09/14/2017 Terms of Use: http://www.asme.org/about-asme/terms-of-use