The robot connects to a computer, which keeps the pieces of the arm working together. This computer is the controller. The controller functions as the "brain" of the robot. The controller can also network to other systems, so that the robot may work together with other machines, processes, or robots. 

Given that the robot arm movement is appropriate to its application, that the arm strength and rigidity meet the payload needs and that servo drives provide the necessary speed of response and resolution, a robot controller is required to manage the arm articulations, its End Effector, and the interface with the workplace.  The simplest type of control, still widely used, is "record-playback," or "lead-through".  An operator positions arm articulations to desired configurations. At each desired location the articulation encoder positions are recorded in memory.  Step by step, an entire work-cycle sequence is recorded.  Then in playback mode the sequence is observed and modified. 

 As applications become more challenging, some jobs require continuous path control of an End Effector. For this action all articulations must be programmed in speeds appropriate to the particular task. This requires programming for the control of the robot. Robots today have controllers run by programs -- sets of instructions written in code. The program sets limits on what the robot can do.  These requirements call into play sophisticated computer-based controllers and so-called robot languages. These languages permit a kind of robot control known as hierarchical control, in which decision making by the robot takes place on several levels. These levels are interconnected by feedback mechanisms that inform the next higher level of the status of previous actions.  The advantage of a general-purpose robot arm is that it can be programmed to do many jobs. The disadvantage is that the programming tends to be a job for highly paid engineers. Even when a factory robot can perform a task more efficiently than a person, the job of programming it and setting up its workplace can be more trouble than its worth. Commotion Systems, a new California firm, is developing easier ways to program robots using pre-designed software modules. For now though, the job of "training" robots is still one of the main reasons that they are not used more. In the future, controllers with Artificial Intelligence could allow robots to think on their own, even program themselves.    This could make robots more self-reliant and independent. Angelus Research has designed an intelligent motion controller for robots that mimics the brain's three-level structure, including instinctive, behavioral, and goal levels. The controller, which can be used in unpredictable circumstances, uses a Motorola 68HC11 microprocessor.

Feedback (Closed Loop) Control

    Feedback control is a means of getting a system (in our case a robot) to achieve and maintain a desired state by continuously comparing its current and desired state.  The desired state is also called the goal state of the system. Note that it can be an external or internal state: for example, a thermostat monitors and controls external state (the temperature of the house), while a robot can control its internal state (e.g., battery power, by recharging at proper times) or external state (e.g., distance from a wall).  If the current and desired state are the same, the control system does not need to do anything. But if they are not, how does it decide what to do? That is what the design of the controller is all about.  A control system must first find the difference between the current and desired states. This difference is called the error, and the goal of any control system is to minimize that error.  In some systems, the only information available about the error is whether it is 0 or non-0, i.e., whether the current and desired states are the same. This is very little information to work with, but it is still a basis for control and can be exploited in interesting ways.  Additional information about the error would be its magnitude, i.e., how "far" the current state is from the desired state. Finally, the last part of the error information is its direction, i.e., is the current state too close or too far from the desires state (in whatever space it may be).  Control is easiest if we have frequent feedback providing error magnitude and direction.  Notice that the behavior of a feedback system oscillates around the desired state. In the case of a thermostat, the temperature oscillates around the set point, the desired setting.  Similarly, the robot's movement will oscillate around the desired state, which is the optimal distance from the wall. How can we decrease this oscillation? We can use a smoother/larger turning angle, and we can also use a range instead of a set point distance as the goal state.  Now what happens when you have sensor error in your system? What if your sensor incorrectly tells you that the robot is far from a wall, but in fact it is not? What about vice versa? How might you address these issues?  Feedback control is also called closed loop control because it closes the loop between the input and the output, i.e., it provides the system with a measure of "progress."

Open Loop Control

 The alternative to closed loop control is open loop control. This type of control does not require the use of sensors, since state is not fed back into the system.  Such systems can operate (perform repetitive, state-independent tasks) only if they are extremely well calibrated and their environment does not change in a way that affects their performance.  We have talked about feedback control so far, but there is also an important notion of feed forward control. In such a system, the controller determines set points and sub-goals for itself ahead of time, without looking at actual state data.

Reactive Control

 Reactive control is based on a tight loop connecting the robot's sensors with its effectors. Purely reactive systems do not use any internal representations of the environment, and do not look ahead: they react to the current sensory information.  Thus, reactive systems use a direct mapping between sensors and effectors, and minimal, if any, state information. They consist of collections of rules that map specific situations to specific actions.  If a reactive system divides its perceptual world into mutually exclusive or unique situations, then only one of those situations can be triggered by any sensory input at any one time, and only one action will be activated as a result. This is the simplest form of a reactive control system.  It is often too difficult to split up all possible situations this way, or it may require unnecessary encoding. Consider the case of multiple sensors: to have mutually-exclusive sensory inputs, the controller must encode rules for all possible sensory combinations. There is an exponential number of those. This is, in fact, the robot's entire sensory space (as we defined earlier in the semester). This space then needs to be mapped to all possible actions (the action space), resulting in the complete control space for that robot.  Although this mapping is done while the system is being designed, i.e., not at run-time, it can be very tedious, and it results in a large look up table which takes space to encode/store in a robot, and can take time to search, unless some clever parallel look up technique is used.  In general, this complete mapping is not used in hand-designed reactive systems. Instead, specific situations trigger appropriate actions, and default actions are used to cover all other cases. Human designers can effectively reduce the sensory space to only the inputs/situations that matter, map those to the appropriate actions, and thus greatly simplify the control system.  If the rules are not triggered by mutually-exclusive conditions, more than one rule can be triggered in parallel, resulting in two or more different actions being output by the system. Deciding among multiple actions or behaviors is called arbitration, and is in general a difficult problem.  Arbitration can be done based on 

•  fixed priority hierarchy (processes have pre-assigned priorities)

• a dynamic hierarchy (process priorities change at run-time)

• learning (process priorities may be initialized or not, and are learned at run-time, once or repeatedly/dynamically)

If a reactive system needs to support parallelism, i.e., the ability to execute multiple rules at once, the underlying programming language must have the ability to multi-task, i.e., execute several processes/pieces of code in parallel. The ability to multi-task is critical in reactive systems: if a system cannot monitor its sensors in parallel, but must go from one to another in sequence, it may miss some event, or at least the onset of an event, thus failing to react in time.  Now that we understand the building blocks of a reactive system (reactive rules coupling sensors and effectors, i.e., situations and actions), we need to consider principled ways of organizing reactive controllers. We will start with the best known reactive control architecture, the Subsumption Architecture, introduced by Rod Brooks at MIT in 1985.

The Subsumption Architecture

The following are the guiding principles of the architecture:

1. Systems are built from the bottom up

2. Components are task-achieving actions/behaviors (not functional modules)

3. Components can be executed in parallel

4. Components are organized in layers, from the bottom up lowest layers handle most basic tasks

5. Newly added components and layers exploit the existing ones

6. Each component provides and does not disrupt a tight coupling between sensing and action

7. There is no need for internal models: "the world is its own best model"

    Here is a rough image of how the system works: If we number the layers from 0 up, we can assume that the 0th layer is constructed, debugged, and installed first. As layer 1 is added, layer 0 continues to function, but may be influenced by layer 1, and so on up. If layer 1 fails, layer 0 is unaffected. When layer 1 is designed, layer 0 is taken into consideration and utilized, i.e., its existence is subsumed, thus the name of the architecture. Layer 1 can inhibit the outputs of layer 0 or suppress its inputs.  Subsumption systems grow from the bottom up, and layers can keep being added, depending on the tasks of the robot. How exactly layers are split up depends on the specifics of the robot, the environment, and the task. There is no strict recipe, but some solutions are better than others, and most are derived empirically.  The inspiration behind the Subsumption Architecture is the evolutionary process, which introduces new competencies based on the existing ones. Complete creatures are not thrown out and new ones created from scratch; instead, solid, useful substrates are used to build up to more complex capabilities.

Behavior Based Control

    Behavior-based systems (BBS) use behaviors as the underlying module of the system, i.e., they use a behavioral decomposition. Behaviors can vary greatly from one BBS to another, but typically have the following properties:

1. Behaviors are feedback controllers

2. Behaviors achieve specific tasks/goals (e.g., avoid-others, find-friend, go-home)

3. Behaviors are typically executed in parallel/concurrently

4. Behaviors can store state and be used to construct world models/representation

5. Behaviors can directly connect sensors and effectors (i.e., take inputs from sensors and send outputs to effectors)

6. Behaviors can also take inputs from other behaviors and send outputs to other behaviors (this allows for building networks)

7. Behaviors are typically higher-level than actions (go-home rather than turn-left-by-37.5-degrees)

8. Behaviors are typically closed-loop but extended in time (this is often a consequence of #7 above)

9. When assembled into distributed representations, behaviors can be used to look ahead but at a time-scale comparable with the rest of the behavior-based system

Behavior-based systems are not limited in the ways that reactive systems are. As a result, behavior-based systems have the following key properties:

1. The ability to react in real-time

2. The ability to use representations to generate efficient (not only reactive) behavior

3. The ability to use a uniform structure and representation throughout the system (so no intermediate layer)

    The key challenge is in how representation (i.e., any form of world model) can be effectively distributed over the behavior structure. In order to avoid the pitfalls of deliberative systems, the representation must be able to act on a time-scale that is close if not the same as the real-time parts of the system. Similarly, to avoid the pitfalls of the hybrid systems approach, the representation needs to use the same underlying behavior structure as the rest of the system.  Note that behavior-based systems can have reactive components to them, i.e., not every part of a behavior-based system needs to be involved with representational computation. In fact, many behavior-based systems did not use complex representations at all. As long as they use behaviors (not just rules), they are BBS.