csci 445 amin atrash - usc robotics research labrobotics.usc.edu/~aatrash/cs445/lec09.pdf · csci...

Introduction to Robotics © L. Itti, M. J. Mataric’

Introduction to RoboticsIntroduction to Robotics

� CSCI 445

� Amin Atrash

�Control Architectures


The Story So Far…The Story So Far…

� Definitions and history

� Locomotion and manipulation

� Sensors and actuators

� Control

� => Essential building blocks


Today’s Lecture OutlineToday’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


Scaling Up ControlScaling 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?


Control ArchitectureControl 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


Why “architecture”? 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


Software ControlSoftware 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


Programming LanguagesProgramming 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


Turing UniversalityTuring 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


Turing EquivalenceTuring 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?


Languages and UsesLanguages 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


Languages & ArchitecturesLanguages & Architectures

� Regardless of the language, a well-designed 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.)


Architecture SpaceArchitecture Space

� We are going to cover the space of robot control architectures: the history, the state-of-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...


Robot Control ArchitecturesRobot Control Architectures

� Deliberative control

� Reactive control

� Hybrid control

� Behavior-based control

� Robotics literature abounds with proposed "novel" control architectures

� Are these novel?


No More Architectures?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.


Power and ExpressivenessPower 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?


Back to Turing EquivalenceBack 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


What is Constrained?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?


Behavior => ArchitectureBehavior => 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...


The EnvironmentThe 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


The TaskThe 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


Sources of DistinctionSources 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?


Criteria for SelectionCriteria 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.)



� 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?



� 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?



� 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?


ComparabilityComparability

� 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...


Looking AheadLooking 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


Time-ScaleTime-Scale

� Time-scale is an important way of distinguishing control architectures

� Reactive systems respond to the real-time requirements of the environment. They work on a short time-scale

� Deliberative systems look ahead (plan). They work on a long time-scale


Combining Time-ScalesCombining Time-Scales

� Hybrid systems include and must combine the two (short and long) time-scales. 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


Textbook ReadingsTextbook Readings

� M 11

csci 445 amin atrash - usc robotics research labrobotics.usc.edu/~aatrash/cs445/lec09.pdf · csci...

Documents