CSCI 445 Amin Atrash. Control Architectures. Introduction to Robotics L. Itti, M. J. Mataric

Transcription

1 Introduction to Robotics CSCI 445 Amin Atrash Control Architectures

2 The Story So Far Definitions and history Locomotion and manipulation Sensors and actuators Control => Essential building blocks

3 Today s Lecture Outline Scaling up control => architectures Architectures v. Languages Turing Universality of Languages Basic classes of architectures Criteria for selection of architecture Looking ahead Time scale

4 Scaling Up Control We have seen feedback control How do we put together multiple feedback controllers in a principled fashion? in what order? with what priority? How do we generate complex, coherent, robust, and adaptive behavior?

5 Control Architecture A control architecture provides a set of principles for organizing a control system. It provides: structure constraints to aid the designer in producing a well-behaved controller

6 Why architecture? The term is used in the same sense as in computer architecture, where it means the set of principles for designing computers out of a collection of well-understood building blocks. Similarly, in robot control architectures, we will use a set of building blocks to program a robot in a reliable fashion

7 Software Control When discussing architectures we are referring to the software control level of the robot, not the hardware Some elements of control can be embedded in hardware, but not all. In general in robotics, we associate control architectures with software for control

8 Programming Languages Any robot control architecture is implemented in some programming language. It is important to realize the distinction between the two! Programming languages are implementational tools Programming languages are not control architectures

9 Turing Universality Any programming language that contains: sequencing conditional branching iteration can compute the entire class of computable functions => This is called Turing Universality All programming languages in use are Turing Universal

10 Turing Equivalence All such Turing Universal languages are called Turing equivalent => Any programming language can be used to implement any architecture. In practice, some programming languages are more convenient than others for specific tasks. E.g., what do we use Lisp, Java, HTML, C, C++, Visual Basic, etc., primarily for?

11 Languages and Uses Programming languages are designed for specific uses. Thus, various languages have been used for robot control: standard (e.g., Lisp, C, C++) specialized (e.g., Behavior Language, Subsumption Language, etc.) Language choice is often more pragmatic than philosophical

12 Languages & Architectures Regardless of the language, a welldesigned controller fits into one of the four control architecture types. Why not always use C/Java/foo? A programming language can be designed so as to facilitate certain architectural practices (e.g., reactivity, tight feedback, symbolic representations, numerical computation, etc.)

13 Architecture Space We are going to cover the space of robot control architectures: the history, the stateof-the-art, the reasons for it. There are infinitely many possible robot programs, but there is a finite (and rather small) number of truly distinct robot architectures. We already mentioned them early on in the semester, and they are...

14 Robot Control Architectures Deliberative control Reactive control Hybrid control Behavior-based control Robotics literature abounds with proposed "novel" control architectures Are these novel?

15 No More Architectures? After several decades of research and testing, all architectures so far fall within one of the four general classes we enumerated earlier Don t be fooled by unprincipled use of architecture and language terminology. Many a robot designer has encoded a new programming language and confused it with a robot architecture.

16 Power and Expressiveness Another confusion exists regarding the issue of fundamental power and/or expressiveness of a robot control architecture Advocates make claims about one control architecture being able to compute fundamentally more than another Can that be true?

17 Back to Turing Equivalence If an architecture is implemented in a Turing Universal programming language, it is fully expressive Since any language can compute any computable function, the architecture on top of it cannot further limit it

18 What is Constrained? Control architectures do not constrain expressiveness Architectures do greatly affect and constrain the structure of the robot controller (e.g., behavior representation, granularity, time scale ) What about the resulting robot behavior?

19 Behavior => Architecture In some cases, it is impossible to tell, just by observing a robot's behavior, what control architecture it is using This is similar to not being able to tell in what language some program is implemented; the function remains the same For simple robots, this is often the case. However, when it comes to more complex robots and environments...

20 The Environment For robots that have to deal with complex environments and tasks, the control architecture becomes very important. Key environment features: presence of sensor/actuator noise static v. dynamic response time of sensors and effectors observability adaptation

21 The Task Another key determinant of the architecture is the nature of the task What does the robot need to do? Consider the example from sensing: object / person recognition finding / grabbing an object moving around etc. The task requirements can constrain the architecture choice

22 Sources of Distinction Behavior representation: how is action represented? Granularity of behavior: what time scale is used for action? Behavior interaction and coordination: how are actions/behaviors chosen? Basis for behavior specification: is a biological model used? Programming methods: is software reusable, supported, user-friendly?

23 Criteria for Selection Support for parallelism: the ability to execute concurrent processes / behaviors at the same time Hardware targetability: how well can it be mapped to robot sensors and effectors; how well the computation can be mapped onto real processing elements (microprocessors, PLAs, etc.)

24 Criteria for Selection Run-time flexibility: is run-time adjustment and reconfiguration (even learning) possible and facilitated? Modularity: how is encapsulation of control handled, how does it treat abstraction? Does it allow many levels, going from feedback loops to primitives to agents? Does it allow re-use of software?

25 Criteria for Selection Niche targetability: how well the architecture allows the robot to deal with its environment Robustness: how well does the architecture perform if individual components fail? How well does it enable and facilitate writing controllers capable of fault tolerance?

26 Criteria for Selection Ease of use: how easy to use and accessible is it? Are there programming tools and expertise? Performance: how well does the robot perform using the architecture? Does it act in real-time? Does it get the job done? Is it failure-prone?

27 Comparability These criteria allow us to compare and evaluate different architectures relative to specific robot designs, tasks, and environments Not all tasks, environments, and designs are comparable => There is no fixed hierarchy or look-up table of the right architecture for a given robot/task/environment...

28 Looking Ahead One way to classify the four types of architectures is by the amount of looking into the future they each do Deliberative: only look-ahead; plan, then execute Reactive: no look-ahead; only react Hybrid: look ahead with the brain but react quickly with the wheels Behavior-based: look ahead only while acting

29 Time-Scale Time-scale is an important way of distinguishing control architectures Reactive systems respond to the realtime requirements of the environment. They work on a short time-scale Deliberative systems look ahead (plan). They work on a long timescale

30 Combining Time-Scales Hybrid systems include and must combine the two (short and long) timescales. This requires a middle layer; => consequently they are often called three-layer architectures Behavior-based systems bring the different time-scales closer by distributing slower computation over concurrent behavior modules

31 Textbook Readings M 11