Robotic Architectures

1. Lezione 8 Robotic Architectures

2. Robotic architecture • Computer architecture: • discipline devoted to the design of highly specific and individual computers from a collection of common building blocks • Robotic architecture: • design of highly specific and individual robots from a collection of common software building blocks. • provides a principled way of organizing a control system • describes a set of architectural components and how they interact • software systems and specifications that provide languages and tools for the construction of robots

3. Common features of behavior-based architectures • There are many behavior-based architectures, but these architectures share many common features: • emphasis on importance of coupling sensing and action tightly • avoidance of representational symbolic knowledge • overall control system is divided into units • But there are also differences: • the granularity of behavioral decomposition • the basis of behavioral specification (ethological, situated activity, experimental)‏ • the response encoding method (null, discrete, continuous)‏ • the coordination method (competitive or cooperative)‏ • programming methods, languages, reusability

4. Behavior based architecture evaluation • Support for parallelism? • Hardware targetability? Mapping from SW to HW? • Niche targetability? • Support for modularity? Encapsulating behavior abstractions? • Robustness? Fault tolerance? • Timeliness in development? Development tools? Simulators? • Run time flexibility? • Performance effectiveness?

5. Subsumption architecture • Task-achieving behaviors in the subsumption architecture are represented as separate layers operating in parallel. Compare with the traditional approach.

6. World Is Its Own Best Model • This is a key principle of reactive systems and Subsumption Architecture: • Use the world as its own best model! • If the world can provide the information directly (through sensing), it is best to get it that way, than to store it internally in a representation (which may be large, slow, expensive, and outdated).

7. Designing in Subsumption • Qualitatively specify the overall behavior needed for the task • Decompose that into specific and independent behaviors (layers)‏ • The layers should be bottom-up and consisting of disjoint actions • Ground low-level behaviors in the robot’s sensors and effectors • Incrementally build, test, and add

8. Arbitration in Subsumption • Arbitration: deciding who has control • Inhibition: prevents output signals from reaching effectors • Suppression: replaces input signal with the suppressing message • The above two are the only mechanisms for coordination • => Results in priority-based arbitration • the rule or layer with higher priority takes over, i.e., has control of the AFSM

9. Example: SR diagram for a subsumption-based foraging robot

10. Subsumption • More general behavior interactions • the building blocks arbitrates among layers in an ad-hoc way

11. Subsumption Larger example -- Genghis • Standing by tuning the parametersof two behaviors: the leg “swing” and the leg “lift” • Simple walking: one leg at a time • Force Balancing: incorporated force sensors on the legs • Obstacle traversal: the legs should lift much higher if need be • Anticipation: handles touch sensors (whiskers) to detect obstacles • Pitch stabilization: uses an inclinometer to stabilize fore/aft pitch • Prowling: uses infrared sensors to start walking when a human approaches • Steering: uses the difference in two IR sensors to follow 57 FSM’s wired together !

12. Case Robot Herbert: subsumption architecture • Developed by Jonathan Connell • Herbert's mission is to collect empty soda cans. • HW: N (max 24) x Hitachi 8bit microprocessor connectedwith 2-wire serial cables (300 baud)‏ • Controlling architecture is using the subsumption architecture • No central bus, no backplane, no blackboard

13. Herbert

14. Part of Herbert’s behaviors

15. Subsumption Evaluation • Strengths: • Reactivity (speed, real-time nature)‏ • Parallelism • Incremental design => robustness • Generality • Weaknesses: • Inflexibility at run-time • Expertise needed in design

16. Schema architecture • Schema is a pattern of action, a basic unit of action from which complex actions are constructed • Two kinds of schemas • Motor schemas and • Perceptual schemas • A schema stores both how to react and the way that reaction can be realized • Provides a language for connecting action and perception • Activation levels are associated with schemas that determine their readiness or applicability for acting • Many systems exists? e.g. Callisto - a foraging robot, GT Hummer

17. What are Schemas? • Schemas are • functional units (intermediate between overall behavior and neural function) for analysis of cooperative competition in the brain • program units especially suited for a system which has continuing perception of, and interaction with, its environment • a programming language for new systems in computer vision, robotics and expert systems • a bridging language between Distributed AI and neural networks for specific subsystems

18. Perceptual And Motor Schemas • A perceptual schema embodies the process whereby the system determines whether a given domain of interaction is present in the environment. • A schema assemblage combines an estimate of environmental state with a representation of goals and needs • The internal state is also updated by knowledge of the state of execution of current plans made up of motor schemas • which are similar to control systems but distinguished by the fact that they can be combined to form coordinated control programs

19. Perception-action schema relationships

20. Example schemas

21. Example schemas

22. Example Schemas

23. Combined schemas

24. Schemas: Deadlock Problem

25. Schemas: Navigational templates

26. Schemas: the effect of using different gain vector values gi

27. Behavioral coordination: action selection

28. Designing with Schemas • Characterize motor behaviors needed • Decompose to most primitive level, use biological guidelines where appropriate • Develop formulas to express reaction • Conduct simple simulations • Determine perceptual needs to satisfy motor schema inputs • Design specific perceptual algorithms • Integrate/test/evaluate/iterate

29. Strengths and Weaknesses • Strengths: • support for parallelism; • run-time flexibility; • timeliness for development; • support for modularity • Weaknesses: • niche targetability; • hardware retargetability; • combination pitfalls (local minima, oscillations)‏

30. Emergent Behavior • Important but not well-understood phenomenon • Often found in behavior-based robotics • Robot behaviors “emerge” from • Interactions of rules • Interactions of behaviors • Interactions of either with environment

31. Distinction • Coded behavior • In the programming scheme • Observed behavior • In the eyes of the observer • Emergence • There is no one-to-one mapping between the two!

32. Why? • sum is greater than the parts • emergent behavior is more than the controller that produces it

33. Interaction and Emergence • Interactions between rules, behaviors and environment • Source of expressive power for a designer i.e., • Systems can be designed to take advantage of emergent behavior

34. Example: Wall Following

35. Example: Wall Following • Can be implemented with these rules: • If too far, move closer • If too close, move away • Otherwise, keep on • Over time, in an environment with walls, this will result in wall-following • Is this emergent behavior?

36. Emergent Wall Following • It is argued yes because • Robot itself is not aware of a wall, it only reacts to distance readings • Concepts of “wall” and “following” are not stored in the robot’s controller • The system is just a collection of rules

37. Emergent Flocking • Program multiple robots: • Don’t run into any other robot • Don’t get too far from other robots • Keep moving if you can • When run in parallel on many robots, the result is flocking

38. Necessary Conditions • Notion of emergence depends on two aspects: • Existence of an external observer, to observe and describe the behavior of the system • Access to the internals of the controller itself, to verify that the behavior is not explicitly specified anywhere in the system

39. Unexpected vs Emergent • Some researchers say the above is not enough for behavior to be emergent, because above is programmed into the system and the “emergence” is a matter of semantics • So emergence must imply something unexpected, something “surreptitiously discovered” by observing the system

40. Subjective Expectations • “Unexpected” is highly subjective, • Because it depends on what the observer was expecting • Naïve observers are often surprised! • Informed observers are rarely surprised

41. Observation and Emergence • Once a behavior is observed, it is no longer unexpected • Is new behavior then “predictable”?

42. Formalization • Look for behaviors that are not apparent at system level (robot’scontroller) but are apparent at observer’s level

43. Execution and Emergence • So now even simple wall following example given can be called “emergent” • This means system has to execute in order for behavior to emerge

44. Uncertainty and Emergence • Not difficult to achieve -- environment is uncertain, so exact behavior of a system is very hard to predict! • If behavior contains novel and rich patterns, then it is “emergent” • If world were completely predictable, then we’d remove “emergent behaviors” by this definition

45. Emergence Is Unavoidable • Some interesting and unexpected behaviors will always emerge in systems that interact with the physical world • Some may be labeled “emergent” • Some are not desirable!

46. Emergent Bugs • Unexpected, emergent behavior that is undesirable • e.g., Oscillations • Try to avoid them, but still want to exploit desirable, unexpected behaviors • System needs to know how to distinguish between the two

47. Sequential vs Parallel • Emergent behaviors can arise from parallel execution of multiple behaviors (e.g., Flocking)‏ • Also from sequential interaction with an interesting environment

48. Architectures and Emergence • Different architectures affect the likelihood of generating and using emergent behaviors • Deliberative: always aim to eliminate them • Reactive: aim to exploit them • Hybrid: typically aim to eliminate them • BBS: aim to exploit them

49. Modularity and Emergence • Modularity directly effects emergence • Reactive and BBS employ parallel rules and behaviors which interact with each other and the environment, thus directly producing and exploiting emergent behavior

50. Avoiding and Exploiting • Hybrid systems follow deliberative model in attempt to produce a coherent, uniform output of the system, minimizing interactions and emergence