A & R 21ME71 Module-5 ppt
A & R 21ME71 Module-5 ppt
Dr. Mohanakumara K C
Assistant Professor,
Dept. of Mechanical Engineering,
ATMECE, Mysuru
Robot programming:
➢ Introduction,
➢ Levels of robot programming,
➢ Requirements of robot programming language,
➢ Problems pertaining to robot
➢ Programming languages,
➢ Offline programming systems,
➢ Central issues in OLP systems,
➢ Automating subtasks in OLP systems,
➢ Simple programs on robot applications.
Robot programming
1. Low-Level Programming
•Purpose: Direct control over robot hardware.
•Features:
• Involves programming specific motor movements, sensor readings, and actuator controls.
• High precision but requires detailed understanding of hardware and electronics.
•Languages: Assembly, C, or other hardware-specific languages.
•Use Cases: Custom robot design, embedded systems, or environments requiring precise, real-time control.
•Example Tasks: Specifying individual joint angles or motor speeds.
2. Intermediate-Level Programming
•Purpose: Abstracts hardware details for simpler task definition.
•Features:
• Uses libraries or APIs provided by robot manufacturers or middleware.
• Incorporates kinematics, dynamics, and path-planning algorithms.
• Easier than low-level programming but still technical.
•Languages: Python, C++, or frameworks like ROS (Robot Operating System).
•Use Cases: Industrial robotics, academic research, and robotics competitions.
•Example Tasks: Programming a robotic arm to follow a trajectory or pick-and-place operation.
Levels of robot programming
3. High-Level Programming
•Purpose: Focus on task-level objectives rather than specific movements.
•Features:
• Employs user-friendly interfaces and programming tools.
• May involve graphical programming, drag-and-drop interfaces, or domain-specific languages.
• Abstracts most technical details, enabling users with minimal technical background to program robots.
•Languages: Custom scripting languages, visual tools, or high-level frameworks (e.g., Blockly, RoboDK, MATLAB/Simulink).
•Use Cases: Collaborative robots, education, or simple automation tasks.
•Example Tasks: Directing a robot to sort objects by color or perform a sequence of predefined tasks.
4. Adaptive/AI-Based Programming
•Purpose: Robots learn and adapt to perform tasks autonomously.
•Features:
• Uses machine learning, neural networks, or reinforcement learning.
• Minimizes explicit programming by enabling robots to learn from data or experience.
• Highly advanced and computationally intensive.
•Languages/Tools: Python (TensorFlow, PyTorch), MATLAB, ROS with AI extensions.
•Use Cases: Autonomous vehicles, humanoid robots, dynamic environments.
•Example Tasks: Navigating a cluttered space, recognizing and manipulating objects, or performing human-like interactions.
Levels of robot programming
▪ This method involves the preparation of the robot program off-line, in a manner similar
to NC part programming.
▪ Off-line robot programming is typically accomplished on a computer terminal.
▪ After the program has been prepared, it is entered in to the robot memory for use during
the work cycle.
▪ The advantaged of off-line robot programming is that the production time of the robot is
not lost to delay in teaching the robot a new task.
▪ Programming off-line can be done while the robot is still in production on the preceding
job.
▪ This means higher utilization of the robot and the equipment with which it operates.
▪ Another benefit associated with off-line programming is the prospect of integrating the
robot into the factory CAD/CAM data base and information system.
REQUIREMENT OF GOOD PROGRAMMING LANGUAGE (ROBOT ORIENTED)
World Modelling
The set up of the work-space and the fixtures and feeders in which the parts are fixed are determined.
Generally robots and the objects are confined to well defined world-space. The positional uncertainty is
minimized by using restricted feeders and fixtures.
Position Specification
The position and orientation of the parts are defined in terms of co-ordinate frame. The feeder and beam
locator and their features are described by using data structures provided by the language.
Motion Specification
The general PNP activity is divided into the sequence of action such as movement of the arm from a
initial configuration to grasp position, picking up an object and moving to the final configuration.
Sensory Control
To take care of the uncertainty in location and dimension of the objects in the work- envelope sensing is
to be performed. The information gathered by the sensors acta as feedback from environment.
Programming Support
The Programming Support like editing and debugging etc are provided by the sophisticated programming
platform for the user to program
Benefits of OLP
Manufacturers who use OLP software report multiple benefits:
•No robot downtime
• Programming time can be reduced up to 80% and robot utilization increased
by as much as 95%, boosting programmer productivity and cutting cell
downtime
•Quick set-up times
• Less time is needed to launch a new product into production – programming
happens concurrently rather than sequentially
•Increased safety
• Reduced risk of accidents and injuries
•Higher and repeatable quality
• Robot programs are better optimized, (shorter cycle times, higher accuracy
and consistency,) resulting in higher and repeatable production quality.
•Robot brand and process agnostic
• Regardless of robot brands or types of processes, advanced OLP software
can cover all applications.
•No more surprises
• Last-minute fixture and tooling modifications are avoided
Disadvantages of OLP Systems
Additional equipment
Offline programming software usually needs to be purchased separately from the robot and requires a computer to run.
• Learning curve
Offline programming software requires some training and can be difficult to use.
• Software capabilities
The software's capabilities may be limited, and you may only be able to use features that the manufacturer has developed.
• Brand lock-in
Using a particular manufacturer's software may tie you into using only their robot brand.
• Cost
Manufacturer simulators can be expensive, and some manufacturers may use a subscription model.
• Virtual vs. real
There can be differences between the virtual and real cells, such as the robot, working zone, parts, fixtures, and clamps.
• Programming steps
Offline programming may require more programming steps than hand-guiding.
Applications of OLP
•Welding – access, and orientation are particular challenges that OLP helps with, and
complex weld beads can require large numbers of points
•Coating (Painting) – as with welding, orientation is important, and so too are unified paint
thickness and standoff distance, plus ensuring all areas can be reached and painted
optimally.
•Dispensing – many assembly operations require the deposition of long, complex adhesive
beads: OLP helps to create the tool paths rapidly offline with consistent quality.
•Processing (Surface) – applications like bead blasting and deburring often need long,
complicated paths that require a lot of points
•Assembly applications (jigless) – grasping and insertion-type moves need precise control
over gripper orientation, which is achieved at a higher level with OLP
•Material handling applications – OLP lets a programmer determine the fastest distance
between two locations, which may not always be the most obvious route
•Cutting – Plasma or laser cutting or waterjet cutting may work for standard parts but for
complex geometries, robots are needed with accurate cutting patterns that can be
generated with OLP.
Off- line programming
VAL:
➢ It is a robot programming language and control system originally designed for use
with Unimation robots.
➢ Its stated purpose is to provide the ability to define robot tasks easily.
➢ The intended user of VAL will typically be the manufacturing engineer responsible for
implementing the robot in a desired application.
➢ It has the structure of BASIC, with many new command words added for robot
programming. It also has its own operating system, called VAL monitor, which
contains the user interface, editor and file manager.
➢ It has been released for use with all PUMA robots and with the Unimate 2000 and
4000 series.
ROBOTIC PROGRAMMING LANGUAGES
ROBOTIC PROGRAMMING LANGUAGES
RAIL: Robotic Automatix Incorporated Language (RAIL) was developed by Automatix for
the use of robots and vision system.
➢ It is an interpreter loosely based on PASCAL.
➢ Several constructs have been incorporated into RAIL to support inspection and arc-
welding systems, which are a major product of Atomatix.
➢ The central processor of RAIL is Motorola 68000.
➢ Peripherals include a terminal and a teach box.
➢ RAIL is being supplied with three different systems:
i. Vision only, no arm
ii. A custom designed Cartesian arm for assembly tasks
iii. A Hitachi process robot for arc welding
ROBOTIC PROGRAMMING LANGUAGES
ROBOTIC PROGRAMMING LANGUAGES
CENTRAL ISSUES IN OLP SYSTEMS
User interface
A major motivation for developing an OLP system is to create an environment that makes programming
manipulators easier, so the user interface is of crucial importance. However, another major motivation is to
remove reliance on use of the physical equipment during programming.
3-D modeling
A central element in OLP systems is the use of graphic depictions of the simulated robot and its work cell.
This requires the robot and all fixtures, parts, and tools in the work cell to be modelled as three-dimensional
objects. To speed up program development, it is desirable to use any CAD models of parts or tooling that are
directly available from the CAD system on which the original design was done.
Kinematic emulation
A central component in maintaining the validity of the simulated world is the faithful emulation of the
geometrical aspects of each simulated manipulator. With regard to inverse kinematics, the OLP system can
interface to the robot controller in two distinct ways. First, the OLP system could replace the inverse
kinematics of the robot controller and always communicate robot positions in mechanism joint space. The
second choice is to communicate Cartesian locations to the robot controller and let the controller use the
inverse kinematics supplied by the manufacturer to solve for robot configurations. T
CENTRAL ISSUES IN OLP SYSTEMS
Path-planning emulation
In addition to kinematic emulation for static positioning of the manipulator, an OLP system should accurately
emulate the path taken by the manipulator in moving through space. Again, the central problem is that the OLP
system needs to simulate the algorithms in the employed robot controller, and such path-planning and-
execution algorithms vary considerably from one robot manufacturer to another. Simulation of the spatial shape
of the path taken is important for detection of collisions between the robot and its environment. Simulation of
the temporal aspects of the trajectory are important for predicting the cycle times of applications.
Dynamic emulation
Simulated motion of manipulators can neglect dynamic attributes if the OLP system does a good job of
emulating the trajectory-planning algorithm of the controller and if the actual robot follows desired trajectories
with negligible errors. However, at high speed or under heavy loading conditions, trajectory-tracking errors can
become important. Simulation of these tracking errors necessitates both modelling the dynamics of the
manipulator and of the objects that it moves and emulating the control algorithm used in the manipulator
controller.
Multiprocess simulation
Some industrial applications involve two or more robots cooperating in the same environment. Even single-robot
workc ells often contain a conveyor belt, a transfer line, a vision system, or some other active device with which
the robot must interact. For this reason, it is important that an OLP system be able to simulate multiple moving
devices and other activities that involve parallelism
CENTRAL ISSUES IN OLP SYSTEMS
Simulation of sensors
Studies have shown that a large component of robot programs consists not of motion statements, but
rather of initialization, error-checking, I/O, and other kinds of statements. Hence, the ability of the OLP
system to provide an environment that allows simulation of complete applications, including interaction
with sensors, various I/O, and communication with other devices, becomes important.
Language translation to target system
An annoyance for current users of industrial robots (and of other programmable automation) is that
almost every supplier of such systems has invented a unique language for programming its product. If an
OLP system aspires to be universal in the equipment it can handle, it must deal with the problem of
translating to and from several different languages.
Work cell calibration
An inevitable reality of a computer model of any real-world situation is that of inaccuracy in the model.
In order to make programs developed on an OLP system usable, methods for work cell calibration must
be an integral part of the system.
AUTOMATING SUBTASKS IN OLP SYSTEMS
Automatic robot placement
One of the most basic tasks that can be accomplished by means of an OLP system is the determination of the work cell
layout so that the manipulator(s) can reach all of the required work points. Determining correct robot or workpiece
placement by trial and error is more quickly completed in a simulated world than in the physical cell. An advanced
feature that automates the search for feasible robot or workpiece location(s) goes one step further in reducing burden
on the user.
Collision avoidance and path optimization
Research on the planning of collision-free paths and the planning of time optimal paths generates natural candidates for
inclusion in an OLP system. Some related problems that have a smaller scope and a smaller search space are also of
interest. For example, consider the problem of using a six-degree-of-freedom robot for an arc-welding task whose
geometry specifies only five degrees of freedom. Automatic planning of the redundant degree of freedom can be used to
avoid collisions and singularities of the robot.
Automatic planning of coordinated motion
In many arc-welding situations, details of the process require that a certain relationship between the workpiece and the
gravity vector be maintained during the weld. This results in a two- or three-degree-of-freedom-orienting system on
which the part is mounted, operating simultaneously with the robot and in a coordinated fashion. In such a system, there
could be nine or more degrees of freedom to coordinate.
AUTOMATING SUBTASKS IN OLP SYSTEMS
Force-control simulation
In a simulated world in which objects are represented by their surfaces, it is possible to investigate the
simulation of manipulator force-control strategies. This task involves the difficult problem of modelling
some surface properties and expanding the dynamic simulator to deal with the constraints imposed by
various contacting situations. In such an environment, it might be possible to assess various force-
controlled assembly operations for feasibility.
Automatic scheduling
Along with the geometric problems found in robot programming, there are often difficult scheduling and
communication problems. This is particularly the case if we expand the simulation beyond a single
workcell to a group of workcells. Some discrete-time simulation systems offer abstract simulation of such
systems, but few offer planning algorithms. Planning schedules for interacting processes is a difficult
problem and an area of research. An OLP system would serve as an ideal test bed for such research and
would be immediately enhanced by any useful algorithms in this area.
Automatic assessment of errors and tolerances
An OLP system might be given some of the capabilities discussed in recent work in modelling positioning-
error sources and the effect of data from imperfect sensors. The world model could be made to include
various error bounds andtolerancing information, and the system could assess the likelihood of success of
various positioning or assembly tasks. The system might suggest the use and placement of sensors so as
to correct potential problems.