CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Patent Application No. 15/789,032, which was filed on October 20, 2017 and U.S. Provisional Application No. 62/485, 159, which was filed on April 13, 2017 and titled "Teach Mode

Collision Avoidance System and Method for Industrial Robotic Manipulators". The entire content of this application is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The present invention pertains to the art of industrial robots and more specifically to controllers for robots operating in a manufacturing environment that prevent the robots from colliding with surrounding objects in their workspace.

BACKGROUND OF THE INVENTION

[0003] Robots are now commonplace in a typical manufacturing

environment. Industrial robots are used in many industries for manufacturing products. For example, in the aerospace industry, robots have been employed to work on components such as wing assemblies and fuselages. Robots, provided with various end effectors and tools, are now moving work pieces around the manufacturing environment at considerable speed. As more robots are employed in the same manufacturing environment, the potential for a collision between a robot, or its tool or end-effector, and other objects in the robot's workspace or even other parts of the same robot increases. Any collision can cause considerable damage to the robot and other objects involved in the collision, resulting in extensive undesirable repair costs and down time in any manufacturing process associated with the robot.

[0004] When a robot is being programed for a new operation and the robot is first being brought online in a workspace, there are higher risks of collision than when a robot is already in operation. The robot is first programmed offline using computer-aided design (CAD) models of the robot and workspace. The path of a tool center point (TCP) of the robot's tool is programmed so that the robot can conduct a manufacturing operation. However, the simulated CAD model of the workspace may not be exactly the same as the actual workspace. To address this issue, most industrial robotic manipulators offer a manual mode, or "teach" mode, where the operator can control the robot using a teach pendant or similar remote control device. Teach mode operation is often used to "touch-up" or adjust offline- created robot programs to account for variation between simulated CAD models, which are employed by the offline programming software, and the as-built workspace. Teach mode operation is used frequently during commissioning of a new robotic workspace and creates a significantly higher risk of collision between the robot, tooling, work piece, and other components in the workspace because a human operator is directly in control of the robot. In some industries, such as aerospace, the high value of the work piece makes the risk of collision

unacceptably high because rework is costly and production schedules are tight.

[0005] To prevent damage from collisions, some robot manufacturers offer collision detection methods that monitor current draw on each of the robot's joint axes to detect when each joint actuator is drawing more than a specified amount of current, possibly signifying a collision. However, normal acceleration and deceleration may also cause higher current draw, making this approach not entirely reliable, as the current monitoring sensitivity must typically be hand-tuned by the operator. Another option, offered by robot manufacturers, as shown in Figure 1 , is a zone-based monitoring feature 10 where the user can define simple polygonal keep-in and keep-out regions 20. During operation, a robot controller 30 monitors various elements 40 of a robot 50 as robot 50 moves relative to a work surface 60, both in teach mode and during normal operation, and immediately halts robot 50 when the robot's motion enters keep-out region 20 or leaves a keep-in region (not shown). However, this zone-based approach is limited in what types of

environments it can monitor. Within the aerospace industry, large curved components such as wing assemblies or fuselages are common, which implies that simple zone-based approaches are not adequate for robotic collision avoidance during teach mode operation. Also, numerous aircraft have features like inlet ducts, and robotic end-effectors can be used for operations inside these ducts (e.g. , coating or de-coating operations). It would be nearly impossible to protect such areas with a zone-based approach because there is a practical limit to the number of zones that can be defined, and each zone is a simple convex polyhedron that does not support complexities like holes (i.e. , toruses are not an option). Other sensor-based approaches can involve outfitting a robot with touch sensors, which can be cost prohibitive to protect all parts of the robot. Non-contact sensors, like 3D laser scanners, could be used to scan the robot and its environment but might not always be able to see all parts of the robot due to "shadows," which occur when a part of the geometry is hidden from the sensor.

[0006] There exists a need in the art to prevent robots from colliding with surrounding objects of complex shape during a teach mode. SUMMARY OF THE INVENTION

[0007] To address the limitations of both sensor-based and zone-based approaches, a new approach has been developed that involves predicting a robot's motion based on teach pendant commands, the robot's current state, and a recent history of past positions of the robot. In this approach, a personal computer is connected to a robot controller during teach mode operation to monitor the robot's motion and predict and prevent collisions. A simulated representation of the environment is used that is an accurate representation of the robot's actual workspace. This simulated representation can come from three-dimensional (3D) CAD models, 3D scan data, or a combination of both. The simulated

representation of the environment is used to perform collision checks between the robot's current and predicted positions to determine whether a collision is imminent while an operator uses the teach pendant to control the robot. The robot system is able to avoid collisions while in teach mode. The teach mode preferably has several sub modes including a jog mode, a step mode, and a run mode, and the system works in all three modes.

[0008] In jog mode, the operator can press buttons on the teach pendant to move each joint of the robot. Alternatively, the operator can also use the buttons to move the tool around in the workspace. In either case, the software "listens" to the button presses, predicts where the robot will move over a time span of several milliseconds (the length of the time period being configurable), and performs collision checks on the robot's predicted path. If a collision is predicted, the robot's override speed is decreased from the desired speed set by the operator. As the robot continues to get closer to an obstacle, its override speed continues to decrease until it comes to a full stop. However, if the operator moves the robot in any direction that will not result in a collision {e.g., along a wall, if the wall is an obstacle, or back away from the wall), then the robot's speed is increased to allow motion in the indicated direction.

[0009] In general, in step mode, the operator can step through a teach pendant program by pressing a "step" button to put the robot in step mode, then a

"forward" or "backward" key to command the robot to execute one step or line of code in the program at a time in the desired direction. In this mode, the software predicts the motion of the robot using its current state and its recent history.

Although complete information regarding the robot's future actions is contained in the teach pendant program, this information is not always made accessible by robot manufacturers. For example, if the robot has been moving in a circular arc over the past several milliseconds (the length of the time period being configurable), the software will predict that the motion will continue along this circular path. This path will then be projected out by several seconds (again, configurable) and pre- checked for collisions. Any predicted collisions will reduce the override speed of the robot. If, however, the robot's motion begins to deviate from the predicted path, the software will "lose confidence" in its prediction and begin to rely on the nearest distance between any part of the robot and a collision geometry, where a collision geometry could be the environment or another part of the robot itself (e.g. , it might be possible for the robot to crash the tool it is holding into its own base). If the nearest distance to a collision decreases beneath a predetermined first threshold (configurable), the robot's override speed is decreased from the desired amount set by the operator, eventually stopping the robot if it reaches a

predetermined second, smaller threshold. If the robot is stopped before reaching the smaller threshold distance, the operator stops the program by releasing the shift key and/or dead-man. The operator can then either use the jog keys to manually retreat or execute another step mode command, possibly in reverse. If the robot has gotten closer than the smaller distance threshold, the user has to activate an override mode by pressing a virtual button on the teach pendant GUI while also holding the shift key and the dead-man. Preferably, password protection is used. This commands the software to enter an override mode. In this mode, the maximum speed of the robot is greatly reduced, allowing the operator to retreat from the collision state at very low speed. Once the robot is out of the collision state, the override mode can be disabled with the teach pendant GUI, and normal operation can resume.

[0010] In run mode, the operator can execute a teach pendant program similar to step mode, although the robot executes lines of code continuously until the user stops execution by releasing the teach pendant key. Otherwise, the prediction and collision avoidance works exactly like step mode, described above.

[0011] More specifically, the present invention is directed to a robot system, which preferably comprises a robot including a manipulator arm for moving along an actual path in an environment containing objects, with the objects and the robot constituting collision geometry. The robot preferably has a base and a manipulator arm configured to hold a tool. The base may comprise one or more joints, sometimes referred to as integrated axes, such as rotary or translational joints that are configured to position the manipulator arm at different locations within the environment. The manipulator arm has at least one joint to allow the tool to be placed in desired positions along the path. The robot is provided with a teach pendant including an operator interface configured to receive operator input entered into the teach pendant. The interface has a keypad with keys. An operator is able to directly control motion of the manipulator arm of the robot along the actual path or control any additional integrated axes by entering instructions with the keys. [0012] The robot system is able to avoid collisions while in a teach mode. The teach mode preferably has several sub modes including a jog mode, a step mode, and a run mode, and the system works in all three modes.

[0013] In one embodiment, a controller is configured to reduce the speed of the robot when any component of the robot approaches the collision geometry such that collisions are prevented while the operator controls the robot directly using the keys in a jog mode. Similarly, the controller is configured to predict the motion of the robot when the operator controls the robot directly in a Cartesian mode, wherein the keys are configured to control the tool center point in Cartesian space.

[0014] In another embodiment, the robot is configured to move according to a program having program steps and acceleration parameters. The controller is further configured to predict the motion of the robot along the predicted path based on a current destination position of a current program step, a speed of the robot, and the acceleration parameters, and to reduce a speed of the robot as the robot approaches the collision geometry along the predicted path such that collisions are prevented.

[0015] In another embodiment, the teach pendant has a key, and the controller is configured to continuously execute steps of the program as long as the operator is pressing the key. A distance between the robot and a nearest point of collision along the predicted path is calculated while the operator is pressing the key, and the speed of the robot is reduced proportionally to the calculated distance.

[0016] In operation, the robot system, including a robot with a manipulator arm, a base that may comprise additional joints, a teach pendant having an operator interface, and a robot controller having a computer and associated hardware and software containing a virtual representation of the robot and the environment, employs the following method for avoiding collisions. The manipulator arm is moved along an actual path in an environment containing objects constituting collision geometry. Operator input is entered into the teach pendant whereby the operator is able to directly control motion of the robot along the actual path. A recent history of the motion of the robot is recorded. A predicted path of the robot is calculated based on the input entered into the teach pendant and the recent history of the motion of the robot. Real-time collision checking between

components of the robot and the collision geometry is performed using the predicted path while the operator manually controls the robot using the teach pendant.

[0017] The method also preferably includes reducing a speed of the robot as the robot approaches the objects in the environment and preventing collisions while the operator controls the robot directly using the keys in a jog mode. The robot is moved according to a program having program steps and acceleration parameters, and the motion of the robot is predicted based on the current

destination position of a current program step, a speed of the robot, and the acceleration parameters. A speed of the robot is reduced as any component of the robot approaches the objects in the environment such that collisions are prevented.

[0018] In another embodiment, the method includes moving the robot according to a program having program steps and predicting the motion of the robot as the robot executes each step of the program. Potential paths of a tool center point of the robot are calculated, and the required robot positions are compared to a history of actual positions. If a path is found to be sufficiently similar to the robot's actual motion, the robot's motion is projected into the future based on the path. A speed of the robot is reduced as any component of the robot is predicted to approach the objects in the environment such that collisions are prevented. A distance between the robot and a nearest point of collision between the robot and the collision geometry is calculated, and the speed of the robot is reduced proportionally to the calculated distance. [0019] Additional objects, features and advantages of the present invention will become more readily apparent from the following detailed description of a preferred embodiment when taken in conjunction with the drawings wherein like reference numerals refer to corresponding parts in the several views.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a schematic drawing of a robot system including a robot and a robot controller according to the prior art.

[0021] Figure 2 is a schematic drawing of a robot system including a robot in accordance with a preferred embodiment of the invention.

[0022] Figure 3 shows a close-up view of a teach pendant from the robot system of Figure 2.

[0023] Figure 4 shows a portion of a robot in accordance with the invention.

[0024] Figure 5 shows a robot near a workpiece in accordance with the invention.

[0025] Figure 6 shows the motion of a part of a robot in accordance with a preferred embodiment of the invention.

[0026] Figures 7A and 7B show a flowchart in accordance with a preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] Detailed embodiments of the present invention are disclosed herein. However, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale, and some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to employ the present invention. The foregoing description of the figures is provided for a more complete understanding of the drawings. It should be understood, however, that the embodiments are not limited to the precise arrangements and configurations shown. Although the design and use of various embodiments are discussed in detail below, it should be appreciated that the present invention provides many inventive concepts that may be embodied in a wide variety of contexts. The specific aspects and embodiments discussed herein are merely illustrative of ways to make and use the invention and do not limit the scope of the invention. It would be impossible or impractical to include all of the possible embodiments and contexts of the invention in this disclosure. Upon reading this disclosure, many alternative embodiments of the present invention will be apparent to persons of ordinary skill in the art.

[0028] With initial reference to Figure 2, there is shown an overall robotic system 100 in accordance with a preferred embodiment of the invention. System 100 includes four main components: a robot 1 10; a robot controller 120; a teach pendant 130, which can be employed by an operator 135; and a personal computer 140. Robot 1 10 includes a base 150 mounted on a surface 155, such as a factory floor, in a workspace or work environment 151. Other configurations where the base comprises one or more translational or rotary stages are also possible but not shown. A lower support 156 is mounted on base 150 so that lower support 156 can rotate relative to base 150 about a first joint 158, as shown by an arrow 157. An upper support 160 is mounted to rotate relative to lower support 156 about a second joint 164, as shown by an arrow 163. Upper support 160 connects lower support 156 to a forearm link 165. The forearm link 165 is pivotably mounted to rotate about a third joint 166, as shown by an arrow 167, and is also designed to extend or retract relative to an arm support 168. So that robot 1 10 can move with six degrees of freedom, robot 1 10 also includes three revolute joints coincident at the wrist of forearm 165, although such joints are not clearly visible in Figure 2. This arrangement allows an end effector or tool 170 to be placed in any desired position by various actuators, such as actuator 172. Based on the above, it should be understood that robot 1 10 includes a plurality of components, e.g., base 150, forearm 165 and tool 170. A component of robot 110, such as tool 170, is moved along an actual path 175 in environment 151 , which contains objects 177, to various desired positions 181 , 182, 183, 184, 185, and 186. Robot 1 10 and objects 177 constitute a collision geometry. Robot controller 120 can include a computer, or be connected to computer 140, that has associated hardware and software (not separately labeled). Preferably, the software runs on computer 140 and monitors the joint positions and joint velocities of robot 1 10. A commercially available software program, which can be modified in accordance with the invention, is Battelle's PathPlan™ software package.

[0029] As best seen in Figure 3, teach pendant 130 includes an operator interface 200 with several keys including a forward key 210 and a backward key 220. During teach mode operation, several modes of controlling robot 1 10 are provided: a jog mode; a step mode; and a run mode. In jog mode, robot 1 10 can be moved around manually using teach pendant keys in operator interface 200.

Individual joints 158, 164, 166 (as well as the joints coincident at the wrist of arm 165) can be moved in joint mode control, or the robot's tool center point 170 can be moved in Cartesian space in Cartesian mode control. Other teach pendant modes can also be used to control robot 1 10 using teach pendant 130, including step mode and run mode. In step mode, operator 135 can execute one line of the robot program in the desired direction by pressing forward key 210 or backward key 220 on teach pendant 130. In run mode, holding down forward or backward key 210, 220 causes multiple lines of code to execute in continuous succession until key 210, 220 is released.

[0030] In jog mode, the control algorithm monitors the teach pendant keys being pressed by operator 135 and predicts the robot's motion accordingly. In joint mode, the algorithm projects the robot's motion by integrating the

commanded joint rate of the specified axis to predict where individual links of robot 1 10 will travel. Figure 4 shows a virtual representation of a robot arm. A base 300 pivotally supports an arm 310 which in turn supports an end effector 320. The position and motion of end effector 320 can be predicted in part based on the lengths of arm 310 and end effector 320 and the angle formed between them

(forward kinematics).

[0031] In Cartesian mode, the algorithm projects the path of the robot's motion in Cartesian space, as shown in Figure 5. Figure 5 shows a virtual representation of a robot 400 with a manipulator arm, such as an arm 410, near a workpiece 450. An end effector 470 is shown in solid at an initial position.

Controller 120 is further configured to reduce a speed of arm 410 when arm 410 approaches the collision geometry {i.e., workpiece 450) such that collisions are prevented while operator 135 controls robot 400 directly using keys of operator interface 200 in jog mode. If robot 400 is being commanded to move in a straight line along the robot's y-axis {e.g. , using a +Y key on teach pendant 130), the algorithm calculates this path and projects it out several seconds into the future. If the robot's position along this projected path, shown by an arrow 480, collides with anything, such as workpiece 450 or another obstacle, a rendering of robot 400 is presented on computer 140 warning of a potential collision, and the algorithm begins decreasing the speed of robot 400 from a desired speed through a range of override speeds. As robot 400 continues to approach workpiece 450, the override speed is decreased until robot 400 is halted. Motion that does not include a predicted collision (including motion that may be close to the workpiece but not toward it, e.g. , along a straight edge) causes the algorithm to increase the speed of robot 400 back to the desired value. For example, moving robot 400 away from workpiece 450 would be done at the desired speed, while moving robot 400 toward workpiece 450 would be done at the override speeds.

[0032] With reference to Figures 2 and 6, controller 120 is configured to record a recent history of the motion of tool 170 along an actual path 650 and associated positions of robot 1 10, develop a predicted path 660 for tool 170 in the virtual representation based on the input entered into pendant 130 and the recent history of the motion of tool 170, and perform real-time collision checking between predicted path, 660 and the collision geometry while operator 135 manually controls robot 1 10 using teach pendant 130. In step mode, operator 135 can sequentially execute each step or program line from a teach pendant program to check the robot's position at each point 61 1 , 612. During this mode, when access to the teach pendant program commands is not possible, a path prediction approach is employed that uses a recent history of the robot's motion and compares it to the predicted motion to determine a confidence level in the algorithm's predictions, as shown in Figure 6. For example, starting at the most recent program step N at time equal to an initial time to in the teach pendant program at 610, the algorithm waits until the robot's tool center position has moved by two steps 61 1 and 612 along actual path 650, with at least a δ distance, shown at 670, between each step to filter out noise. Once the algorithm has sufficient data for three steps, it calculates a best-fit circular arc and best- fit linear segment to fit the tool center point samples. At each sample point, the algorithm then performs inverse kinematics to determine the required joint angles 0 of robot 1 10 to achieve the calculated tool center point position. Because the initial joint angles Oo are known at to, only consistent inverse kinematic solutions are selected for ti and t ₂ (e.g., alternate configurations where the elbow is flipped can be eliminated from consideration). The history of robot positions is then compared to the calculated positions to determine a similarity measure. Methods such as Dynamic Time Warping, commonly used for measuring similarity between two temporal sequences that may vary in speed, can also be used to analyze the history of the robot positions, especially if there are different numbers of samples between the actual robot data and the calculated robot data. If the two data streams are sufficiently similar, the selected path is used to predict the robot's motion by several seconds into the future and check for collisions. If a collision is predicted, the robot's speed is decreased from a desired speed to an override speed or through a range of override speeds. In Figure 6, for example, circular path 660 best fits the data when compared to linear path 665, although the algorithm will only select this path if the actual robot position history is sufficiently like the calculated inverse kinematics solutions. If this is true, the algorithm has high confidence that circular path 660 is the true path.

[0033] Until the algorithm has sufficient data samples or if the algorithm cannot arrive at a confident prediction of the robot's path (e.g. , the robot is executing a joint move where the tool center position path does not match either the linear 665 or circular arc 660 projected paths), the nearest distance between robot 1 10 and the collision geometries (including robot 1 10 itself) is used to modulate the robot's speed. If robot 1 10 is closer than a pre-specified threshold, the speed will be reduced towards zero. Once robot 1 10 is closer than a second, smaller threshold, the speed will be set to zero or sufficiently close to zero to eliminate risk of collision (e.g. , 0.01%, which looks and feels to the operator like a dead halt). In run mode, path prediction is difficult because sufficient data is not always exposed by the robot manufacturer during robot operation. For this reason, the algorithm utilizes nearest distance to track how close robot 1 10 is to colliding with its environment or itself to modulate the robot's override speed, like step and jog modes.

[0034] Figures 7 A and 7B show a flowchart for a collision avoidance algorithm 700. Algorithm 700 operates in a loop where robot state data (joint positions and rates, control flags such as button presses, the program running flag, etc.) is obtained from robot controller 120 at each servo time step. The entire flowchart describes the action taken during one iteration of the loop and starts at a step 702. Once robot state data is obtained at 704, software algorithm 700 checks robot 1 10 against a simulated environment generated from 3D CAD and/or 3D scan data. If a collision is predicted, the algorithm halts robot 1 10 by clamping the override speed S to 0 at step 796, as shown in the continuation of the flow chart in Figure 7B. If no collision is predicted, algorithm 700 uses logical flags from controller 120 to determine at 712 if operator 135 is running a program on teach pendant 130, which would indicate either step or run mode. If not, operator 135 must be using jog mode, in which case algorithm 700 determines if a teach pendant jog button is being pressed (e.g. , J1+, J1 -, etc., where Jl is the robot's first, or base, joint). If no keys are being pressed at 714, robot 1 10 is maintained in the halted state by clamping the override speed to 0 (Path C at 796 in Figure 7B). If a jog button is pressed, algorithm 700 determines at 716 whether joint mode is being used by looking at the associated logical flag from controller 120. In joint mode, joint rates are measured from the controller data at 718. In Cartesian mode, the tool center point is moved linearly in Cartesian space by operator 135 using the keys of operator interface 200. The keypress is converted to a direction, then inverse kinematics is performed to determine calculated joint rates that can be used to determine projected robot positions 720. Controller 120 is configured to predict the motion of the arm or tool center point when operator 135 controls robot 1 10 directly in the Cartesian mode. In both joint and Cartesian modes, the robot's position is projected out into the future at 720 based on the calculated or measured joint rates and passed to the next part of the algorithm at 725 (shown in Figure 7B).

[0035] The other major path shown in Figure 7A is for step and run modes. Robot 1 10 is configured to move tool 170 according to a program having program steps and acceleration parameters, and controller 120 is configured to predict the motion of tool 170 along predicted path 660 based on a current destination position of a current program step, a speed of tool 170, and the acceleration parameters. Controller 120 is further configured to reduce a speed of tool 170 as any

component of robot 1 10 approaches collision geometry along predicted path 660 such that collisions are prevented. If a program is running, then algorithm 700 determines if sufficient motion planning data is available from robot controller 120 at 730. This can include the current program step, the current destination position of robot 110, acceleration and deceleration parameters, etc. If this information is available, then an accurate prediction of the robot's motion is possible, and the robot positions are projected into the future at 720 and passed to the Path A portion of the algorithm, shown in Figure 7B, at 725. If this data is not available at 730, which is the more general case, then algorithm 700 determines which mode, step or run, is active at 732. If run mode is active, algorithm 700 moves to 755 and resorts to using the minimum calculated distance to a collision between robot 1 10, environment 151 , and itself at a step 742, which is shown in Path B of Figure 7B. Once the minimum distance is calculated at step 742, the clamping factor is decreased based on a monotonically decreasing function if the minimum distance is less than a configuration threshold at 744. If step mode is active at 732, however, algorithm 700 then determines whether joint mode or Cartesian mode is active based on control flags at 734. If joint mode is active, algorithm 700 resorts to the minimum distance approach at 755 as there will be no well-defined path evident in Cartesian space. If Cartesian mode is active at 734, however, the robot's current state is recorded at 736, and algorithm 700 then determines whether enough samples have been recorded to predict the robot's motion at 738. As discussed previously, predicting a line 650 or circular arc 665 generally requires a minimum number of samples for a high-quality estimate, although the actual number depends on the motion options available to robot 1 10, the robot's control algorithm 700, and the amount of noise in the samples. If insufficient samples are available, algorithm 700 resorts to the minimum distance approach at 755. If there are sufficient samples, at 740, algorithm 700 best fits the various motion options (e.g. , linear, circular, etc.) to the samples, calculates the required inverse kinematic solutions to achieve these samples based on a known starting state, and compares each set of inverse kinematic solutions to the actual history of robot joint positions. If, at 742, one set of calculated inverse kinematic solutions is sufficiently like the actual history of robot positions, algorithm 700 has high confidence that robot 1 10 will be executing the associated path. The projected inverse kinematic solutions are then passed at 725 to Path A in Figure 7B and checked for singularities and collisions, similar to the jog mode discussed above. If no calculated path is sufficiently similar to the actual history of robot positions, then algorithm 700 resorts to the minimum distance approach described in Path B of Figure 7B. Once all paths of algorithm 700 have been completed, the execution returns to the beginning at 702, where new data is obtained from controller 120.

[0036] Generally, in Paths A, B, and C in Figure 7B, a clamping factor is calculated that is used to clamp the desired override speed to a safe value. In Path A, the clamping factor is set to 100% at 760, and then the projected positions are checked for singularities at 764. Singularities are important because, at these positions in the robot's workspace 151 , the robot's motion is more difficult to predict as robot controller 120 may handle each robot singularity differently, and there is generally insufficient information from controller 120 to determine what will happen. In addition, around singularities, the robot's joints may move very quickly, making it more difficult to prevent collisions. To mitigate these risks, the robot's speed is automatically reduced around singularities at 766 to prevent the robot's joints from moving too quickly and to provide algorithm 700 with additional time to react.

[0037] Once the singularity check is complete along Path A, algorithm 700 then checks the projected robot positions for potential collisions at 768. If any are detected, the clamping factor is reduced based on the time until the impending collision at 770. The closer in time that a collision would occur, the greater the reduction. Various function profiles are possible, including nonlinear functions, although the simplest case of a linear function is shown in Figure 7B. After the collision check is complete, the clamping factor is then passed to the final block where it is used to clamp the desired override speed of robot 1 10. If the clamping factor is 100%, meaning that no singularities or collisions were detected, then the override speed is set equal to the desired speed at 780. If the clamping factor has been reduced, the desired speed is clamped to this value only if the desired speed exceeds this value. This means that operator 135 can jog robot 1 10 at the desired speed if that speed is considered "safe", i.e. , it is below the clamping factor.

Algorithm 700 then returns, at a step 790, to the beginning (step 702).

[0038] Although described with reference to preferred embodiments of the invention, it should be readily understood that various changes and/or

modifications can be made to the invention without departing from the spirit thereof. For instance, while reference has been made to controlling robots working on parts of an aircraft in the aerospace industry, the invention is applicable to any moving robot having parts that could be involved in a collision. In general, the invention is only intended to be limited by the scope of the following claims.