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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 3 Trajectory Generation 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

Robotics II Copyright Martin P. Aalund, Ph.D. 4 Trajectory Generation 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 7 Trajectory Generator Cubic Spline Quintic Spline S curve

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

9

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

Robotics II Copyright Martin P. Aalund, Ph.D. 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 a 2 and a 3

Robotics II Copyright Martin P. Aalund, Ph.D. 12 Cubic Continued So the an are If the initial and final velocity is zero then So finally the acceleration is given by or

Robotics II Copyright Martin P. Aalund, Ph.D. 13 Cubic Example Given –Positions –And each segment should last 1 second.

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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 t b –If the acceleration is not high enough it will take longer than t h 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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

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

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

Robotics II Copyright Martin P. Aalund, Ph.D. 23 Issues with Cartesian Path Planning Intermediate Points Unreachable Unreachable due to Limits Singularities

Robotics II Copyright Martin P. Aalund, Ph.D. 24 Intermediate Points Unreachable

Robotics II Copyright Martin P. Aalund, Ph.D. 25 Unreachable due to Limits

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

Robotics II Copyright Martin P. Aalund, Ph.D. 27 Motor Model K

Robotics II Copyright Martin P. Aalund, Ph.D. 28 Motor Design and Equations Basic Electrical Equations K t and K v are the same in SI units.  

Robotics II Copyright Martin P. Aalund, Ph.D. 29 Motor Continued Mechanical Time Constant Electrical Time Constant

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 34 Robot Programming Languages (RPL) 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++

Robotics II Copyright Martin P. Aalund, Ph.D. 35 Robot Programming Languages (RPL) 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 38 Off-line Activities User Programming Tool Task Level Program Visualization Solid Modeller Feature Based Task Model Action-Level Program Simulation CAD Database Generates Robot Level Programs

Robotics II Copyright Martin P. Aalund, Ph.D. 39 On-line Activities Robot-Level Program Geometric Model Kinematics Dynamics Joint Controller RTOS Sensing Robot Safety Vision AMPs

Robotics II Copyright Martin P. Aalund, Ph.D. 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)

Robotics II Copyright Martin P. Aalund, Ph.D. 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.

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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

Robotics II Copyright Martin P. Aalund, Ph.D. 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