This is the most common method of automatic programming. Programming by Demonstration (PbD) systems may use touch/pendants for the demonstration, or they may use other, more natural communication methods such as gestures and voices.
A traditional PbD system uses a teach-pendant to demonstrate the movements the robot should perform. This technique has been used for industrial manipulators for many years. The demonstrator performs the task using the teach pendant. The position of the pendant is recorded and the results used to generate a robot program that will move the robot arm through the same motions. Alternatively, the demonstrator may move the robot arm through the required motions either physically or using a controller. Though simple, this type of system has been effective at rapidly creating assembly programs.
There are two current PbD research directions. The first is to produce better robot programs from the demonstrations. The second is to enhance demonstration through the use of multi-modal communications systems.
Significant work has been conducted in recent years to develop PbD systems that are able to take the information produced from a demonstration, such as sensor and joint data, and extract more useful information from it, particularly for industrial tasks. Traditional PbD systems simply record and play back a single demonstration with no variation to account for changes or errors in the world. Much current research aims to introduce some intelligence to PbD systems to allow for flexible task execution rather than pure imitation.
Blog about Robotics Introduction, news of the robot, information about the robot, sharing knowledge about the various kinds of robots, shared an article about robots, and others associated with the robot
Robot Automatic Programming Systems
Automatic programming systems provide little or no direct control over the program code the robot will run. Instead, robot code is generated from information entered into the system in a variety of indirect ways. Often a robot system must be running while automatic “programming” is performed, and these systems have been referred to as “online” programming systems. However, automatic programming may also be performed on simulated or virtual robots, for example in industrial robotic CAD systems. In this case the real robot is off-line but the virtual robot is online. For example, the IGRIP (2003) system provides full simulation capabilities for creating and verifying robot programs.
The three categories that automatic systems can be placed into: learning systems, programming by demonstration (PbD) and instructive systems. Learning systems create a program by inductive inference from user provided examples and self-exploration by the robot. In the long run it will be crucial for a robot to improve its performance in these ways.
Examples include a hierarchy of neural networks developed for learning the motion of a human arm in 3D (Billard and Schall, 2001), and a robot that can learn simple behaviours and chain these together to form larger behaviours. Smart and Kaelbing (2002) propose reinforcement learning for programming mobile robots. In the first phase the robot watches as the task is performed. In the second phase the robot attempts to perform the t ask on its own.
The three categories that automatic systems can be placed into: learning systems, programming by demonstration (PbD) and instructive systems. Learning systems create a program by inductive inference from user provided examples and self-exploration by the robot. In the long run it will be crucial for a robot to improve its performance in these ways.
Examples include a hierarchy of neural networks developed for learning the motion of a human arm in 3D (Billard and Schall, 2001), and a robot that can learn simple behaviours and chain these together to form larger behaviours. Smart and Kaelbing (2002) propose reinforcement learning for programming mobile robots. In the first phase the robot watches as the task is performed. In the second phase the robot attempts to perform the t ask on its own.
Robot Behaviour based Languages
Behaviour-based languages provide an alternative approach to the procedural languages. They typically specify how the robot should react to the different conditions, rather than providing a procedural description. A behavioural system is more likely to be used by a robot developer than the end user. The developer would use it to define functionality that the end user would use to perform tasks.
Functional Reactive Programming (FRP) is a good example of a behavioural programming paradigm. In FRP, both continuous and discrete events can be used to trigger actions. Recently, there have been two language extensions of note based on a functional language. These systems allow the programmer to specify how the robot reactions using very little code compared with procedural languages. The descriptions are based on behaviours and events.
FRP is not limited to languages such as Haskell. Dai et al (2002) have implemented an FRP system in C++. It provides similar functionality to Frob, but also allows existing C++ code. One obvious trend is the change away from simple, command based languages, and towards higher-level languages that provide more support to the user, which is illustrated by the increasing popularity of behavioural languages. With more intelligent programming systems, the programmer is required to do less work to achieve the same results, increasing productivity.
Functional Reactive Programming (FRP) is a good example of a behavioural programming paradigm. In FRP, both continuous and discrete events can be used to trigger actions. Recently, there have been two language extensions of note based on a functional language. These systems allow the programmer to specify how the robot reactions using very little code compared with procedural languages. The descriptions are based on behaviours and events.
FRP is not limited to languages such as Haskell. Dai et al (2002) have implemented an FRP system in C++. It provides similar functionality to Frob, but also allows existing C++ code. One obvious trend is the change away from simple, command based languages, and towards higher-level languages that provide more support to the user, which is illustrated by the increasing popularity of behavioural languages. With more intelligent programming systems, the programmer is required to do less work to achieve the same results, increasing productivity.
Robot Generic Procedural Languages
Generic languages provide an alternative to controller-specific languages for programming robots. “Generic” means a high-level multi-purpose language, for example, C++, that has been extended in some way to provide robot-specific functionality. This is particularly common in research environments, where generic languages are extended to meet the needs of the research project. The choice of the base language varies, depending upon what the researchers are trying to achieve. A language developed in this way may be aimed at system programming or application level programming.
The most common extension to a multi-purpose language is a robot abstraction, which is a set of classes, methods, or similar construct that provides access to common robot functions in a simple way. They remove the needs to handle low-level functionality such as setting output port high to turn on motors or translating raw sensor data. It might also provide higher-level abstractions, such as methods to make the robot move to a point using path planning. It is common now for a research robot from a manufacturer to provide such a system with their robots.
To improve this situation, many researches have developed their own robot abstraction systems. Player/stage is commonly used robot programming systems, which provides drivers for many robots and abstractions for controlling them. To prevent the abstractions from being limited to one robot architecture, they use Java classes to provide common abstractions and programming interfaces.
The most common extension to a multi-purpose language is a robot abstraction, which is a set of classes, methods, or similar construct that provides access to common robot functions in a simple way. They remove the needs to handle low-level functionality such as setting output port high to turn on motors or translating raw sensor data. It might also provide higher-level abstractions, such as methods to make the robot move to a point using path planning. It is common now for a research robot from a manufacturer to provide such a system with their robots.
To improve this situation, many researches have developed their own robot abstraction systems. Player/stage is commonly used robot programming systems, which provides drivers for many robots and abstractions for controlling them. To prevent the abstractions from being limited to one robot architecture, they use Java classes to provide common abstractions and programming interfaces.
Roomba the Simpler Robots
Robots are complex machines and significant technical knowledge and skill are needed to control them. While simpler robots exist, for example the Roomba vacuuming robot from iRobot., in these cases the robots are specifically designed for a single application and the control method reflects this simplicity. The Roomba robot’s control panel allows a user to select different room sizes and to start the vacuuming process with a single button push.
However, most robots do not have simple interfaces and are not targeted side’s single, simple function such as vacuuming floors. Most robots have complex interfaces, usually involving a text-based programming language with few high-level abstractions. While the average user will not want to program their robot at a low level, a system is needed that provides the required level of user control over the robot’s tasks.
Robots are becoming more powerful, with more sensors, more intelligence, and cheaper components. As a result robots are moving out of controlled industrial environments such as homes, hospitals and workplaces where they perform tasks ranging from delivery services to entertainment. It is this increase in the exposure of robots to unskilled people that requires robots to become easier to program and manage it.
However, most robots do not have simple interfaces and are not targeted side’s single, simple function such as vacuuming floors. Most robots have complex interfaces, usually involving a text-based programming language with few high-level abstractions. While the average user will not want to program their robot at a low level, a system is needed that provides the required level of user control over the robot’s tasks.
Robots are becoming more powerful, with more sensors, more intelligence, and cheaper components. As a result robots are moving out of controlled industrial environments such as homes, hospitals and workplaces where they perform tasks ranging from delivery services to entertainment. It is this increase in the exposure of robots to unskilled people that requires robots to become easier to program and manage it.
Robot Controller Specific Languages
Controller-specific languages were the original method of controlling industrial robots, and are still the most common method today. Every robot control has some form of machine language, and there is usually a programming language to go with it that can be used to create programs for that robot. These programming languages are usually very simple, with a BASIC-like syntax and simple commands for controlling the robot and program flow. A good example is the language provided by KUKA for its industrial robots. Programs written in this language can be run on a suitable KUKA robot or tested in the simulation system provided by KUKA.
Despite having existed for as long as industrial robots have been in use, controller-specific languages have seen only minor advances. In one case, Freund and Luedemand-Ravit (2002) have created a system that allows industrial robot programs to be generalized around some aspects of a task, with a customized version of the robot program being generated as necessary before being downloaded into a robot controller. The system uses a “generation plan” to provide the basic program for a task. For example, a task to cut shaped pieces of metal could be customized by the shape of the final result. While such a system can help reduce the time for producing programs for related products, it does not reduce the initial time to develop the robot program.
Despite having existed for as long as industrial robots have been in use, controller-specific languages have seen only minor advances. In one case, Freund and Luedemand-Ravit (2002) have created a system that allows industrial robot programs to be generalized around some aspects of a task, with a customized version of the robot program being generated as necessary before being downloaded into a robot controller. The system uses a “generation plan” to provide the basic program for a task. For example, a task to cut shaped pieces of metal could be customized by the shape of the final result. While such a system can help reduce the time for producing programs for related products, it does not reduce the initial time to develop the robot program.
Robot Manual Programming Systems
Users of a manual programming system must create the robot program by hand, which is typically performed without the robot. The finished program is loaded into the robot afterwards. These are often off-line programming systems, where a robot is not present while programming. It is conceivable for manual programming to control a robot online, using for example an interpreted language, where there are no safety concerns.
Manual programming systems can be divided into text-based and graphical systems (also known as icon-based systems). Graphical programming is not considered automatic programming because the user must create the robot program code by hand before running it on the robotic system. There is direct correspondence between the graphical icons and the program statements.
A text-based system uses a traditional programming language approach and is one of the most common methods, particularly in industrial environments where it is often used in conjunction with Programming by Demonstration. Text-based systems can be distinguished by the type of language used, in terms of the type of programming performed by the user.
A manual system programming may use a text-based or graphical interface for entering the program. The text-based systems contain controller specific languages, generic procedural languages, and behavior based languages. Graphical systems contain graph systems, flowchart systems, and diagrammatic systems.
Manual programming systems can be divided into text-based and graphical systems (also known as icon-based systems). Graphical programming is not considered automatic programming because the user must create the robot program code by hand before running it on the robotic system. There is direct correspondence between the graphical icons and the program statements.
A text-based system uses a traditional programming language approach and is one of the most common methods, particularly in industrial environments where it is often used in conjunction with Programming by Demonstration. Text-based systems can be distinguished by the type of language used, in terms of the type of programming performed by the user.
A manual system programming may use a text-based or graphical interface for entering the program. The text-based systems contain controller specific languages, generic procedural languages, and behavior based languages. Graphical systems contain graph systems, flowchart systems, and diagrammatic systems.
Subscribe to:
Posts (Atom)
