Robotics II Copyright Martin P. Aalund, Ph.D. 1 Trajectory Generation Provide a method of computing robot motions required to perform a high level task

Robotics II Copyright Martin P. Aalund, Ph.D.

1

Trajectory Generation

• Provide a method of computing robot motions required to perform a high level task

• Must allow a user to describe trajectories at a high level– Pick A

– Place B

• Describe trajectories in terms of the tool not the joints– If the user specifies the desired position and orientation of the tool

– The trajectory generator will calculate the required joint velocities and accelerations to arrive at the final destination.


2

Trajectory Generation Issues

• How do we represent trajectories.– Do we care about orientation

– How do we store

– Do we care about velocity

• How the path is actually calculated– Real-time

– In advance

• How they are planned or taught.

• How they can be modified– If one point changes how does it effect the path.

• What if we need to change the path in real-time (obstacle avoidance)

• How much computation do we need


3


• We have a tool frame {T} (current position)

• We have a station frame {S}

• Want to generate accelerations and velocities at the joints to drive the {T}={S}

• {S} may be changing as a function of time.

• May want to travel through via-points and or avoid obstacles– Via-Points can be represented as frames.

• This de-couples the planning phase from the particular kinematics of the robot.

• Cartesian path does not need to be regenerated for different tool.

• Need to check that accelerations or velocities are not to great for the robot to track.

• Also must consider joint limits


4


• Spatial– Concerned with Position

– Just want to get to the Final point or Frame.

• Temporal – Concerned with Time

– May want to have a certain velocity when reaching the goal or a via-point.

• Force Trajectories– Impedance control

• Hybrid– Track Position along some coordinates

– Track Force along others


5

Joint Based

• Points Are Taught in Cartesian Space

• Trajectory Generator Converts Points from Cartesian Space to Joint Space– Inverse Kinematics

• Between Points Joints are Moved in a Linear item.– All joints arrive at end of motion at same item

– Joints move at different Rates

• Robot may not follow a straight line

• Cannot follow a path

• Computationally low

• Avoids singularities


6

Cartesian

• Generates Intermediate Points in Cartesian Space.

• Then Convert each point to Joint Space.

• Accurate Path following

• Computationally intensive

• Singularities can be an issue.

• Joints may saturate for small Moves


7

Trajectory Generator

• Cubic Spline

• Quintic Spline

• S curve


8

Step Accelerations

-15

-10

-5

0

5

10

15

0 2 4 6 8 10

Time

0

2

4

6

8

10

12

A

V

J

P


9

Step J

-2

-1

0

1

2

3

4

5

6

7

8

9

0 2 4 6 8 10

Time

F(t

)

0

5

10

15

20

25

30

35

J

A

V

P


10

How do we Define a Path (Cubic)

• Lets Look at a simple example for 1 Joint or DOF– We Know ,

– We also Know ,

– Want to find , , and

– Where

• So we have four Constraints lets try a Cubic polynomial

0 f

0 f

tt

t

tt

t

33

2210 tatataat

t t t


11

Cubic Continued

• To determine the coefficients we need to look at our boundry conditions. Namely:– Position at t=0

– Velocity at t=0

– Position at t=final

– Velocity at t=final

• Plugging these in we get.

• Solving for a2 and a3

2321 32 tataat

33

2210 tatataat

10 a 00 a

232 320 fff tatat 3

32

200 ffff tatatt

fff

f

f ttta

1230022

02033

12 f

f

f

f tta


12

Cubic Continued

• So the an are

• If the initial and final velocity is zero then

• So finally the acceleration is given by or

fff

f

f ttta

1230022

02033

12 f

f

f

f tta

01 a 00 a

033

2 f

fta01 a 00 a 022

3 f

fta

ttt

t f

f

f

f

0302

126 taat 32 62


13

Cubic Example

• Given– Positions

– And each segment should last 1 second.

00 50

0f

15v

0.40f

sec

5.17

v


14

Quintic Polynomial

• Cubics allow us de fine the position and velocity at each location in the trajectory.

• If we also want to specify the acceleration we would need a Quintic or order 6 polynomial.

• This time we would use the initial and final positions, velocities and accelerations as our boundary conditions to solve for the coefficients.

55

44

33

2210 tatatatataat


15

Linear Functions

• Another alternative is just to just linearly interpolate between the starting and end position. – This would use a constant velocity along the whole trajectory.

– However this creates a discontinuity in the velocity at the beginning and the end.

– This would require infinite acceleration.

• To avoid this parabolic blends are applied at the beginning and end of the trajectories.– A simple ramp velocity scheme is often used.

– This results in Step (discontinuities) in the acceleration.

– The velocity of the linear section must equal the velocity at the end of the first blend and the velocity at the beginning of the second blend.

bh

bhb tt

t


16

Linear Functions Cont.

• The position at the end of the blend is given by

• Combining these equation we get

• If we specify the desired duration t of motion and the acceleration we can calculate tb – If the acceleration is not high enough it will take longer than th to reach

full speed.

• Parabolic blends can be used for via points.– This however results in the via points never being actually reached.– If we need to actually hit a via point. Two pseudo via points on either

side of the via point can be added that would result in the via point being on the new linear section.

– Care must be taken to make sure that adequate accelerations are selected such that there is sufficient time to get to the linear sections.

20 2

1bb t

002 fbb ttt


17

Cartesian Space Schemes

• Even thought Straight line paths are followed in joint space this does not guarantee that the robot will follow a straight line.

• If we want to describe the path shape followed by the end-effector then we need to generate our trajectories in Cartesian space.– Most common is linear others include:

– Circular

– Sinusoidal

– Hyperbolic

• Each point is usually specified in terms of desired position and orientation of a tool frame.– Can describe each point as a 6x1 vector.

– Can be planned directly from users definitions of {T} relative to a given {S}

– Usually specified in 6 DOF, but other sub-spaces could be used.


18

Cartesian Schemes

• Spline functions similar to those developed for joints can be used between Cartesian position– In this case each X, Y, Z, roll, pitch and yaw would each be splined.

– Blend times for each degree of freedom must be the same.

– This will result in different accelerations for each DOF

– Blend times must be chosen to limit accelerations.

• More computationally intensive.– Must convert each position on the path to joint space.

– This requires inverse kinematics for position

– The inverse Jacobean for velocities

– And the inverse Jacobean plus for accelerations.


19

Cartesian Path Problems

• Even though a path can be specified in Cartesian space a robot may not be able to follow it.

• Common problems include– Unreachable points due to workspace limitations

• Ex. Cant reach center for 2DOF short outer link.

– High Joint rates due to singularities in workspace• Ex 2DOF with same link lengths.

– Joint Limits• Ex robot cant pass through dead zero and stay on path.


20

Extensions to Path Planning

• Dynamics can be used to generate torque speed curves as a function of position this can allow higher overall accelerations.– Real time

– Lookup table

• Obstacle Avoidance– Gravity Wells

– Distance based modeling

– Dynamically changing workspaces


21

Homework

• 6.3

• 6.9

• 6.15

• 7.1

• 7.2

• 7.9

• 7.10


22


23

Issues with Cartesian Path Planning

• Intermediate Points Unreachable

• Unreachable due to Limits

• Singularities


24

Intermediate Points Unreachable


25

Unreachable due to Limits


26

Singularities


27

Motor Model

K


28

Motor Design and Equations

• Basic Electrical Equations

• Kt and Kv are the same in SI units.

gm

te

v

bJ

iKt

iLKiRV

gt bJiK


29

Motor Continued

• Mechanical Time Constant

• Electrical Time ConstantB

Jtm

R

Lte


30

Robot Programming Languages (RPL)

• The Economic viability of a robot system is usually determined by how easy it is to perform the required task. Thus the robot is usually judged by the programming language that it uses.

• Concerned with observing and manipulating objects in free space– Must deal with physical objects

• Used for Two Purposes– Define the task the robot is to perform.

– Control the Robot at it performs the task.

• Need to Support three classes of Users– User

– Application

– System


31

User or Operator

• Normally has no training in programming experience

• Responsible for the control of the robot in the application

• Requires a simple intuitive interface– Select Programs

– Start/Stop Programs

– Teach Points

• Most likely will not resemble a programming language – Teach Pendant

– GUI

• Safety of Operator and Environment is Critical


32

Application Programmer

• Skilled in the application– Welding

– Semiconductor

• Prefer to program at task or action level not at robot– Place carton on pallet

– Weld Seam

• Most RPL only enable programming at the Robot Level– Move to Station A, Pick, Move to Station B Place

• Most application level environments are interpreted– Easier to write programs

– Easier to Debug

• Research– Academic is focused on action programs

– Industry focused on simulation


33

System Programming

• Usually skilled in Science or Engineering

• Build, develop and support application environments

• May extend the RPL.

• Need access to the operating system.

• Need Real-Time support

• Interface with sensors

• Need to be able to extend the environment

• One or more system programmers may write an application environment for welding. Application engineers may develop applications for five different processes for an automotive plant. Users may use the application on three shifts and at 5 locations.


34


• In the Past Three Approaches have been used for Robotics Languages– Create From Scratch

• VAL (Shimano, 1979)

• LM (Latrobe et al, 1985)

• WAVE (Paul, 1976)

– Modify or Extend an Existing Computer Language• RAPT extension of ATP (Hollingshead, 1985)

• MCL (Manufacturing Control Language)

– Modify or Extend an Existing Computer Language• TCL

• C, C++


35


• Control Physical Motions

• Support Operation in Parallel– Joints must move in Parallel

– Data from sensors

• Communicate with other Programs and Processes– Shared Memory

– Remote Procedure Calls

– Message Passing

• Synchronize with External Events

• Respond to Interrupts

• Operate on Sensor Variables

• Initiate and Terminate in Physically Safe Ways


36

RPL

• Sensor Variables– Must be updated independent of programs that use them

• Type of Motion

• Complex Paths

• Control of Trajectory following

• Aborting motion

• Error Detection*

• Error Recovery*

* Most difficult, tedious, and time consuming to design, develop and debug.


37

Computer Languages as RPL

• Computer Programming Language– Manipulate Data– Data Storage– Flow Control

• Extension for Robots– Events: Used for Synchronization External and Internal Events– Data Types and Aggregates

• Distant Types• Vectors• Matrices• Rotations• Frames

– Motion Control– Extended I/O

• Sensor Interaction• Data Logging


38

Off-line Activities

User

Programming Tool

Task Level Program Visualization

Solid ModellerFeature BasedTask Model

Action-LevelProgram

Simulation

CAD Database

Generates Robot Level Programs


39

On-line Activities

Robot-Level Program

Geometric Model

KinematicsDynamics

Joint ControllerRTOS

Sensing Robot

Safety

Vision

AMPs


40

Popular Languages (Custom Hardware)

• KAREL– Programming language of GMF Fanuc Robots

– Used heavily in Automotive industry.

• AML: A Machine Language– Developed by IBM

– Designed to be a generic language.

– Ran a SCARA 7535 and a Cartesian robot.

• RAIL– Developed by Automatics, Inc.

– Designed for both Vision and Robotics

• VAL– Robot programming language of Unimation (PUMA)


41

Popular Languages Open Hardware

• Cimetrix– Built on top of Window NT

– Client Server architecture• Client can be Simulation or Robot

– Uses Motion Card for Joint level Motion

– Uses TCL as scripting language

• Trellis– Based on Karel programming Language

– Uses Real-Time UNIX OS

– Uses Motion Card for Joint level Motion

• V+– Created by Adept

– VME Based Hardware

– Used on Staubli and Adept robots

– Stand-Alone controller are available.


42

Teaching a Robot• Manual

– Robot joints are released

– Joints are moved manually to a desired position

– Positions of joints are Recorded

– Easy to do if there is access to the robot

– Can be used to develop a continuos path.

• Via Point– Robot moved to desired points along trajectory that the robot is required to pass through

– Position of joints is recorded at each position

– End Points are also defined

– Usually uses a teach pendant

• Programmed Points– Points are developed off-line

• Simulation

• Entered manually

– Points are sweetened by stepping through the program

• Automatic Programming– Points generated off-line

– Points automatically Sweetened


43

Errors in Environment or Model

• Sometimes Points cannot be taught accurate in advance– Errors in models

– Changing environments

– Difference in robot repeatability and accuracy

• Station can be taught in Real-Time– Vision

– Laser Striping

– Tactile Sensing

– Through Arc Sensing

– Other Sensors

• Welding

• Wafer Alignment


44

Errors in Environment or Model

• Compliance– Pin in Hole

– Delicate objects

• Torque Sensors– Used as feedback

– Can minimize forces

• Micro Manipulators– Used for small accurate motions

– Used to reject disturbances

Documents

Robotics II Copyright Martin P. Aalund, Ph.D. 1 Trajectory Generation Provide a method of computing robot motions required to perform a high level task