Robot programming languages 0 Three Levels of Robot Programming: 1, Teach by Showing: The robot is moved to a desired position manually, and its location is recorded in the controller's memory. During playback, the controller follows the recorded positions. The robot is guided using a teach pendant (handheld device with buttons) or by hand. Allows control over individual robot joints or Cartesian degrees of freedom. Some pendants include logic testing and branching capabilities, and may have alphanumeric displays, becoming more complex like hand-held terminals. 2. Explicit Robot Programming Languages With the advent of powerful computers, robots began to be programmed using specialized programming languages called Robot Programming Languages (RPLs). These languages often include features tailored to controlling robots. The key types of robot programming languages are: Specialized Manipulation Languages: These languages are built specifically for robot control, often focusing on manipulator tasks. Early versions (¢.g., VAL) had weaknesses such as lack of floating-point support, string handling, and limited subroutine features. Later versions like V-II and V+ improved these features. Some, like AL, were developed in academic settings and introduced concepts like force control and parallelism. Example: VAL (by ‘Unimation, Inc.) and AL (developed at Stanford University). Robot Library for Existing Computer Languages: These are existing general-purpose programming languages (e.g, BASIC, Pascal) extended with libraries of robot-specific subroutines. Users write programs in the base language, frequently calling robot-specific subroutines for robot control. Example: AR-BASIC (subroutine library for BASIC), JARS (based on Pascal, developed by NASA). Robot Library for New General-Purpose Languages: These are new general-purpose programming languages with added robot-specific libraries. A new language is created as a base, which includes predefined subroutines designed for robotic tasks, offering flexibility and functionality. Example: RAPID (by ABB Robotics), AML (by IBM), KAREL (by GMF Robotics). 3. Task-Level Programming Languages Task-level programming languages represent a higher level of robot programming. These languages allow users to specify broad tasks or subgoals (¢.g., “grasp the bolt") without detailing every step the robot must take. Key features include: High-Level Commands: Users issue high-level instructions, and the system automatically handles the detailed planning (e.g., path planning, obstacle avoidance, and choosing optimal grasp locations) Automation of Planning: The system autonomously manages complex tasks like motion planning and decision-making, reducing the programmer's workload compared to explicit robot programming languages. Distinction from Explicit Languages: While incremental improvements are being made to explicit robot programming languages, true task-level programming, where the robot handles the complexity of task execution, is still an ongoing area of research, ‘A sample application: Figure 12.2 shows an automated workcell that completes a small subassembly in a hypothetical manufacturing process. The workcell consists of a conveyor under computer control that delivers a workpiece; a camera connected to a vision system, used to locate the workpiece on the conveyor; an industrial robot equipped with a force-sensing wrist; a small feeder located on the work surface that supplies another part to the manipulator; a computer-controlled press that can be loaded and unloaded by the robot; and a pallet upon which the robot places finished assemblies. The entire process is controlled by the manipulator's controller in a sequence, as followFigure: An automated workcell containing an industrial robot. 1. Conveyor Start & Detection: The conveyor starts, and the system stops once a bracket is detected by the vision system. 2. Vision System Inspection: The vision system checks the bracket’s position, orientation, and quality (€-., defects like incorrect holes). 3. Robot Grasping: The robot uses the vision system data to grasp the bracket with a specified force. If grasping fails, the vision system repeats the task. 4, Placement on Work Surface: The bracket is placed in a fixture on the work surface. The conveyor resumes for the next bracket, and steps 1 and 2 can run in parallel. 5. Pin Insertion: A pin is picked from the feeder and inserted partway into the bracket using force control. Ifthe feeder is empty, the operator is notified. 6. Bracket-Pin Placement: The robot places the bracket-pin assembly into a press for further processing. 7. Press Actuation: The press presses the pin fully into the bracket. Upon completion, the press signals the robot. 8. Force Sensing for Quality Check: The robot checks the pin insertion quality by sensing the reaction force and measuring the pin's protrusion. 9. Final Assembly Handling: If the assembly is good, it is placed on a pallet. If the pallet is full, the operator is alerted. Ifthe assembly is bad, itis discarded. 10. Parallel Process Continuation: After completing Step 2, the system resumes Step 3, repeating the process for subsequent parts Requirements of a robot programming language: World Modeling: » |e (render) (Tg) 7 FIGURE: Often, a workeell is modeled simply, as a set of frames attached to relevant objects,1. Geometric Types for Manipulation: Robot programming uses geometric types (e.g, joint) angles, Cartesian positions, and frames) to describe motions and object relationships in 3D space. 2. World Model Representation: In many systems, the world model is created by defining variables for objects (e.g., robot, parts, fixtures), which represent frames or other geometric types. These models focus on spatial relationships rather than physical properties, 3. Affixment of Objects: Some systems support "affixing" objects together, so when one object, moves (e.g, the bracket), any attached objects (e.g., the pin) move automatically with it. 4, Advanced World Modeling with CAD Data: More advanced world models may incorporate CAD-style data, representing objects’ shapes, edges, surfaces, or volumes, enabling more complex tasks like collision detection and path planning. 5. Task-Level Programming: Detailed world models allow robots to perform more sophisticated tasks, such as assembly, by understanding spatial and physical relationships, which is a key feature of task-level programming systems. Motion specification: A very basic function of a robot programming language is to allow the description of desired motions of the robot. Through the use of motion statements in the language, the user interfaces to path planners and generators of the style. Motion statements allow the user to specify vvia points, the goal point, and whether to use joint-interpolated motion or Cartesian straight-line motion. Additionally, the user might have control over the speed or duration of a motion. To illustrate various syntaxes for motion primitives, we will consider the following example manipulator motions: (1) move to position "goal 1," then (2) move in a straight line to position "goal2," then (3) move without stopping through "vial" and come to rest at "goal3." Assuming these entire path points had already been taught or described textually, this program segment would be written as follows: In VALI, Move goal 1 Moves goal 2 Move vial Move goal 3 In AL (here controlling the manipulator "garm"), Move garm to goal 1; Move garm to goal 2 linearly; Move garm to goal 3 via vial; Flow of execution: 1. Execution Flow Includes testing, branching, looping, subroutine calls, and interrupts. 2. Parallel Processing is common in automated workcells to improve efficiency. Multiple robots may work simultaneously to reduce cycle time. In single-robot setups, other workcell equipment must be controlled concurrently. 3. Signal & Wait Primitives are used for synchronizing parallel tasks and managing communication between different parts of the system. 4. In Event Monitoring sensors detect events, and the robot system must respond. Interrupts: Immediate response to events, Polling: Periodic checking of sensor status. 5. Advanced Constructs: Some robot programming languages offer sophisticated parallel execution and event monitoring features for easier control of complex systems. Programming environment: 1. As with any computer languages, a good programming environment fosters programmer productivity. Manipulator programming is difficult and tends to be very interactive, with a lot of trial and error. 2. If the user were forced to continually repeat the “edit-compile-run" cycle of compiled languages, productivity would be low. 3. Therefore, most robot programming languages are now interpreted, so that individual language statements can be run one at a time during program development and debugging.4. Many of the language statements cause motion of a physical device, so the tiny amount of time required to interpret the language statements is insignificant. 5. Typical programming suppor, such as text editors, debuggers, and a file system, are also required. Sensor integration: |. Robot systems must query touch and force sensors and use responses in decision-making (ifthen- else constructs) and support event monitors for background sensor transitions. 2. Vision systems provide object coordinates, enabling the manipulator to adjust its position based on object location and orientation relative to the camera. : 3. Sensors from other workcell equipment, like a conveyor belt, can provide input to the robot for tracking and acquiring objects in motion. 4. Special language statements allow robots to apply force strategies, integrating force control into the manipulator's control system. 5. Active force control allows programmable stiffness in motion, with force specifications (e.g., 2er0 stiffness and bias force) as part of motion commands for precise force appli For example, move garm to goal with stiffness=(80, 80, 0, 100, 100, 100) with force=20*ounces along zhat; Problems peculiar to robot programming languages: Internal World Model vs. External Reality: 1. World Model in Robots: Robots rely on an internal world model to represent the physical environment, but ensuring this model matches reality is challenging. 2. Discrepancies Cause Issues: Differences between the internal model and the real world can result in problems like poor object grasping, collisions, and other errors. 3. Limited Accuracy: The robot's manipulator has limited precision, often making tasks like inserting small pins difficult due to insufficient accuracy. 4. Refining Positional Data: Sensors (vision, touch) or force feedback can help improve the accuracy of object positioning when exact locations are uncertain, 5. Difficulties in Undoing Actions: In robotics, actions like drilling or welding physically alter objects, making it hard to "undo" mistakes. This may require replacing objects or repeating earlier steps to get the system back to the correct state. Context sensitivity 1. Bottom-Up Programming Approach: In manipulator programming, combining small, independent program pieces into a larger program can be problematic due to context-sensitive issues. 2. Initial Conditions Matter: Manipulator programs are sensitive to initial conditions, such as starting position, which can impact motion trajectory and velocity, especially in cubic-spline joint- space paths. 3. Relocation Issues: Moving manipulator motions to different locations within the workcell often requires "tuning" the program, as location changes affect configuration, accuracy, and can lead to larger arm movements and kinematic errors, 4, Trajectory and Workspace Challenges: The shape and nature of motion trajectories can change bbased on the manipulator's position in its workspace, especially near singularities, affecting both Joint-space and Cartesian path methods, 5. Slow Testing and Speed Variations: I's advisable to test motions slowly to avoid collisions and inspect them, as increasing speed after debugging can cause servo errors, affect force control strategies, and impact accuracy, especially in contact situations. Error recovery: 1. Objects may not always be where expected, causing motions to fail (¢.g., objects shifting, dropping, jamming during insertion), 2, Requires explicit tests in the program to detect failures. ©3. Tests might include checking position, force, or using vision systems to detect missing or misplaced objects. 4. Position checks during insertion (no change = jam, too much change = 5. Visual checks to confirm object presence and location. 6. Force checks to verify the object is held correctly. 7. It's hard to predict all possible errors, so only high-risk parts are typically checked, 8. Error recovery code can become complex and take up significant program space. 9. Recovery attempts can introduce new errors. 10, Multiple processes running concurrently can complicate error recovery. 11, Some errors can be handled by backing up the offending process, while others may require resetting multiple processes. 12, Testing and interaction with the robot during program development is crucial to identify likely failure points and improve error recovery. jssed hole). Offline Programming: ‘This method involves programming the robot using a computer without the need for physical interaction . with the robot. The programmer creates a virtual environment that simulates the robot's movements, and - the program is tested and debugged before being uploaded to the robot. Central issues in OLP systems: 1 User interface 1) A major motivation for developing an OLP system is to create an environment that makes programming manipulators easier. b) However, another major motivation is to remove reliance on use of the physical equipment during programming. ©) Manufacturers of industrial robots have learned that the RPLs they provide with their robots cannot be utilized successfully by a large percentage of manufacturing personnel. 4) For this reasons, many industrial robots are provided with a two-level interface, one for programmers and one for nonprogrammers. e) Nonprogrammers utilize a teach pendant and interact directly with the robot to develop robot programs. 4) » Programmers write code in the RPL and interact with the robot in order to teach robot work points and to debug program flow. 2) For use as an RPL, interactive languages are much more productive than compiled languages. h) A well-designed user interface should enable nonprogrammers to accomplish many applications from start to finish. 2. 3-D modeling a) A central clement 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 modeled as three- mensional objects ©) To speed up program development, itis 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. 4) If an OLP system is to be a stand-alone system, it must have appropriate interfaces to transfer models to and from external CAD systems. ¢) An important use of the three-dimensional geometry of the object models i detection, example in assembly 3. Kinematic emulation a) A central component in maintaining the validity of the simulated world is the faithful emulation of the geometrical aspects of each simulated manipulator. b) 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. 4) 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. automatic collision€) The simulator must use the same algorithm as the controller in order to avoid potentially catastrophic errors in simulating the actual manipulator Path-planning emulation a) 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. b) 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. ©) When a robot is operating in a moving environment (e.g., near another robot), accurate simulation of the temporal attributes of motion is necessary to predict collisions accurately. 5. 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. b) However, at high speed or under heavy loading conditions, trajectory tracking errors can become important. ©) Simulation of these tracking errors necessitates both modeling the dynamics of the manipulator and of the objects that it moves and emulating the control algorithm used in the manipulator controller. 4) Currently, practical problems exist in obtaining sufficient information from the robot vendors to make this kind of dynamic simulation of practical value, but, in some cases, dynamic simulation ccan be pursued fruitfully. 6. Multi process simulation ) Some industrial applications involve two or more robots cooperating in the same environment, ») Even single-robot workcells often contain a conveyor belt, a transfer line, a vision system, or some other active device with which the robot must interact. reason, itis important that an OLP system be able to simulate multiple moving devices and other activities that involve parallelism. 4) Adding signal and wait primitives to the language enables the robots to interact with each other just as they might in the application being simulated. 7. Simulation of sensors a) 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. b) Hence, the ability of the OLP system fo provide an environment that allows simulation of complete applications, including interaction with sensors, various VO, and communication with other devices, becomes important. ©) An OLP system that supports simulation of sensors and multiprocessing not only can check robot motions for feasibility, but also can verify the communication and synchronization portion of the robot program. 8. Language translation to target system ‘a) 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. b) One choice for dealing with this problem is to choose a translating to and from several different languages. ©) One choice for dealing with this problem is to choose a single language to be used by the OLP system and then post process the language in order to convert it into the format required by the target machine. 4) An ability to upload programs that already exist on the target machines and bring them into the OLP system is also desirable. ©) Two potential benefits of OLP systems relate directly to the language translation topic. f) Having single, universal interface, one that enables users to program a variety of robots, solves the problem of learning and dealing with several automation languages. 8) A second benefit stems from economic considerations in future scenarios in which hundreds or perhaps thousands of robots fill factories. 9. Workcell calibration ‘a) In order to make programs developed on an OLP system usable, methods for workcell calibration ‘must be an integral part of the system. °)'b) The magnitude of this problem varies greatly with the application; this variability makes off-line programming of some tasks much more feasible that of others. ©) If the majority of the robot work points for an application must be re taught with the actual robot to solve inaccuracy problems, OLP systems lose their effectiveness. 4) Many applications involve the frequent performance of actions relative to a rigid object. ©) For example, PC-board component insertion, routing, spot welding, arc welding, palletizing, painting, and deburring. Automating subtasks in OLP systems: Automatic robot placement: Determines robot workcell layout for reaching all workpoints, using simulation to avoid trial-and-e Uses direct or heuristic-guided search to find feasible robot or workpiece positions. Focuses on dividing 3D space to find a collision-free position for the robot base. Ensures the robot can reach workpoints without collisions, potentially optimizing for manipulability or well-conditioned configurations. In a workcell layout where the robot can efficiently access all required points in safe, optimal configurations. Collision avoidance and path optimization: Research on the planning of coffision-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. 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 modeling some surface properties and expanding the dynamic simulator to deal with the constraints imposed by various contacting situations. 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 Automatic assessment of errors and tolerances: ‘An OLP system might be given some of the capabilities discussed in recent work in modeling positioning- + error sources arid the effect of data from imperfect sensors. The world model could be made to include various error bounds and tolerance information, and the system could assess the likelihood of success of various positioning or assembly tasks,