1 / 43

Software Engineering in Robotics Reference Architectures

Software Engineering in Robotics Reference Architectures. Henrik I. Christensen – hic@cc.gatech.edu. Outline. Introduction Architectures? Review of prototypical architectures Some implementation considerations Summary. Introduction. Architecture is about providing structure

muriel
Download Presentation

Software Engineering in Robotics Reference 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. Software Engineering in RoboticsReference Architectures Henrik I. Christensen – hic@cc.gatech.edu

  2. Outline • Introduction • Architectures? • Review of prototypical architectures • Some implementation considerations • Summary

  3. Introduction • Architecture is about providing structure • Design principles for methods, classes, services, systems • Common design principles • Structure – organization & control • Behavior – control implementation • Conventions – names, … • Documentation • Organization to optimize use • Cost • Re-use • Flexibility • Foot-print [Wikipedia]

  4. Architecture • Typically we consider three different camps • Sense-Plan-Act • Behavior based • Hybrid Deliberative Architectures • Each approach has it range of pros and cons. • Typically we need to consider • Support for parallelism • Hardware targetability • Support for modular design • Robustness • Run-time flexibility • Performance effectiveness • Documentation

  5. Design Dimensions • Temporal decomposition • Parallelism • Control decomposition

  6. Temporal decomposition • Division according to temporal requirements • Provides a coarse division of control • Layering can be loosely synchronous • Some layers may be missing Off-line planning Strategic planning Tactical planning Quasi Real-Time Hard Real-Time

  7. Example for mobile platform • Division to ensure safety • Consideration for environmental dynamics • Hardware support influences design Path Planning 0.1Hz Range based Obstacle Avoidance 1 Hz Emergency stop 10Hz PID Speed Control kHz

  8. Control Decomposition • Sense Plan Act – well known, widely used • Parallel decomposition has some advantages for targeted designs • Behavior based designs may be suited for situated control with clear context Sense Plan Act World Go To Goal Arbitration Arbitration Act Arbitration World

  9. Hybrid Deliberative Architecture • Architecture to interleave deliberation and reactive control • Provides high degree of flexibility • Widely used in mobile robotics

  10. Example of foraging - FSA Start Wander Acquire Begin Detect Release Grab Retrieve Halt Done

  11. Foraging in TeamBots • Example

  12. Subsumption architecture

  13. Augmented Finite State Model Reset Suppressor Behavior Module Input Output Inhibitor

  14. Example of a three layer robot Lost Collide Reverse Go Wander Forward Drive Run Away Brakes

  15. Coordination in subsumption • Inhibition prevents signals transmitted from reaching actuators • Suppression replaces a signal transmitted by the suppressing signal • The end result is a priority based arbitration method

  16. Design of subsumption systems • Qualitative specify the behavior need for the task(s) • Compose and specify the independent behaviors as a set of disjoint actions • Determine behavior granularity • Ground low level behavior onto sensors and actuators

  17. Subsumption foraging robot - Nerd Homing Pickup S Avoiding S Wandering S [Mataric, USC & MIT]

  18. Evaluation - Subsumption Advantages Weaknesses • Compiles to HW • Support for parallelism • Well adopted to niches • Poor run-time flexibility • Hardwired control • Behavior re-use is hard

  19. Motor Schema • Based on motor schema theory [Arbib, 1981] • Large grain modularity • Distributed concurrent agents • Assemblage composition • Strong coupling to neuro- / cognitive modeling.

  20. Design Strategy • Response represented as uniform vectors • Cooperative coordination through superposition • Predefined hierarchy – arbitration / orchestration • Arbitration is implicit through gains

  21. Motor Schemas

  22. Example Schema Based System PS1 ES1 MS1 PS2 Robot ES2  Motor ES3 PS3 MS2 PS4 ES: Environment SensorPS: Perceptual Schema MS: Motor Schema

  23. Representative schemas

  24. Example composition

  25. Animal parallel

  26. Design with Motors Schemas • Characterize motor behaviors needed • Compose the primitive control – use biological inspiration where appropriate (ex grasping, …) • Develop model to generate response mappings • Perform simulations to model interactions • Determine perceptual needs for motor schemas • Design perceptual schemas to provide data • Integrate / Test / Evaluate / Iterate

  27. Foraging Example Wander Generate Direction Noise Detect Obstacles Avoid Obstacle Detect Robots Avoid Obstacle Acquire Noise Generate Direction Detect Obstacles Avoid Obstacle Sequencer Detect Robots Avoid Obstacle Detect Attractor Move to goal Deliver Generate Direction Noise Detect Obstacles Avoid Obstacle Detect Robots Avoid Obstacle Detect Home Base Move to goal

  28. Evaluation – Motor Schema Advantages Weaknesses • Support for parallelism • Run-time flexibility • Timeline for development • Support for modularity • Niche targetability • Hardware retargetability

  29. DAMN Architecture

  30. DAMN Architecture Avoid Obstacle Mode Manager Maintain Heading Follow Road DAMN arbiter Vehicle Controller Seek Goal Avoid Tip-Over

  31. DAMN - NAVLAB [frc.ri.cmu.edu, 1992]

  32. DAMN Evaluation Advantages Weaknesses • Easy design of behaviors • Easily extendable • Loose synchronization • Difficult to analyze stability • Could exhibit chatter • Difficult to integrate

  33. Hybrid Deliberative Architecture (AuRA)

  34. AuRA Architecture

  35. Example of Hybrid Deliberative Arch • BERRA a system for tour guiding / office delivery • Designed in by CAS @ KTH • Experiments in robot design

  36. BERRA

  37. BERRA Architecture

  38. CoSy Architecture Schema Toolkit (CAST)

  39. CAST Example Schema

  40. CAST Architecture Example

  41. Relation to RDS • The integration of systems can in almost all cases be mapped directly to RDS • CCR allow handling of all the communication issues • DSS can map directly to the CAST model of system design • For arbitration mechanisms there is a need to consider a class for “voting” arbitration. • The time dimension can be directly mapped to data handlers (Dispatcher / TaskQueues)

  42. Summary • There are a number of reference architectures available in literature. • Reactive architecture (Subsumption, …) • Deliberative architectures (NASREM, RCS) • Hybrid Deliberative • Consider adoption path • What are reference models for services? • What is the appropriate arbitration/coordination framework? • Potential field, Voting based, Fuzzy, … • Frameworks scales better

  43. Acknowledgement • This series of lectures has been developed with generous support from the Microsoft Corporation as part of the project “Software Engineering in Robotics” Contract # 113873. The support is gratefully acknowledged.

More Related