1 / 50

Robotic Architectures

Lezione 8. Robotic Architectures. Robotic architecture. Computer architecture : discipline devoted to the design of highly specific and individual computers from a collection of common building blocks Robotic architecture :

joynera
Download Presentation

Robotic Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related