1 / 15

Robot Software

For Regular Seminar Robot Software Dec. 23, 2003 Jaesoo Lee jslee@redwood.snu.ac.kr RTOS Lab., SoEECS, SNU Contents Requirements of Robot Software History of Robot Software Architecture SPA (Sense-Plan-Act) Subsumption Hybrid Our Robot Software Architecture

issac
Download Presentation

Robot Software

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. For Regular Seminar Robot Software Dec. 23, 2003 Jaesoo Lee jslee@redwood.snu.ac.kr RTOS Lab., SoEECS, SNU

  2. Contents • Requirements of Robot Software • History of Robot Software Architecture • SPA (Sense-Plan-Act) • Subsumption • Hybrid • Our Robot Software Architecture • Unexplored Issues Requiring Further Research • Remarks on Robot Research

  3. Robot Software - Requirements • Basic capabilities: deliberation + reactivity • Requirements • Programmability – easiness of introducing new goals • Autonomy and adaptability – aware current goal, execution context • Consistent behavior – reactions guided by objectives • Robustness – fault tolerance • Extensibility – pluggable, reusable, and reconfigurable components • Coordination – multiple goals, multiple (redundant) sensors

  4. SPA (Sense-Plan-Act) • Features • Unidirectional and linear flow of control • Easy execution of a plan (task execution) • Partial orderings, conditionals, and loops • Shortcomings • Planning and world modeling are very hard problems • Open-loop plan execution is inadequate in uncertain and unpredictable environment • Very slow !!

  5. Subsumption • Vertical (hierarchical) decomposition of tasks • Behaviors in higher layer implement more complex, specified task • Each behavior still follows SPA architecture • “The World is its own best model” • No internal models, sense the surroundings on need instead • Direct, ego-centric, and distributed perception • Lisp-like languages to describe behaviors (Augmented Finite State Machine and connecting wires)

  6. Subsumption Level 2: explore Level 1: wander every 10sec Level 0: avoid objects reset

  7. Subsumption • Advantages • Good reactiveness, inherent concurrency • The lower levels have no awareness of higher levels • Competitive coordination with inhibition and suppression mechanisms • Provides a development architecture to incrementally build and test a complex system • Shortcomings • Bad modularity • Upper layers interfere-with/depend-on the internal functions of lower-level behaviors • Increasingly complex • Bad runtime flexibility • Priorities are hardwired • No support for reverse suppression • No global planning

  8. Hybrid Architecture • Goal: reactive planning • Slow planning (SPA, vulnerable to stale decision) • + fast reactivity (Subsumption, subject to fail on sensor errors) • Approach: reintroducing/separating planning • Organization: Plan, (“Sequencing”), Sense-Act

  9. Hybrid Architecture • 3 layer architecture • Deliberate/planning/deliberator • State reflecting predictions about the future • Reasoning, deliberation, planning, world modeling • Task-execution/sequencing/sequencer • State reflecting memories about the past • Coordination of multiple tasks • Reactive/skill/controller/behavior • No state, relying on current knowledge • Tight feedback control loops Ex. NASA 3T Architecture

  10. Huddles and The Trends • Planning, world modeling and increasing complexity of autonomous mobile robot system are turned out to be huddles very hard to solve. • Among these, AI and robot people are trying to solve the complexity problem by eliminating direct communications between modules • TCA by Reid Simmons at CMU • Central Control Module, one of framework component, routes messages, manages resources, and executes task sequences • CORBA is getting used for telerobotics

  11. Our Approach • Applications in our view point • Implements task to achieve specific goals • By concatenating behaviors using partial orderings, parallel executions, conditionals and loops • Has activation conditions, parameter lists, and affinity

  12. Robot software component architecture Componentization Modularity, reusability ORB middleware & component model Communications Modularity Robot software component communication architecture Deployment, implementation Transparency, efficiency, reusability, retargetability, time-to-market UML-based development tool Integrated robot simulator Design, implementation, simulation, packaging Our Approach

  13. Unexplored Issues • Middleware issues on QoS • End-to-end QoS (deadline, delay, jitter, throughput) • Global priority • Reservation-based vs. priority-based communication • Collocated optimization • Schedulability analysis based on constraints annotation • Control quality • Clock synchronization • Real-time event, time-triggered event

  14. Unexplored Issues • Architectural issues • Robot software component communication architecture • Prioritized suppression/inhibition • Subscription/Un-subscription of sensor data • Application affinities • Sequencer service • Reconfiguration on-the-fly and permanent storage • Accustom the robot • Affinities and default parameters for applications • Learning results, acquired landmarks, constructed maps • Requires corresponding supports of underlying ORB, OS, and hardware

  15. Remarks on Robot Research • We can do constructing framework better than them, but how about planning and controls ? • Even though our approach seems to be on the right way, our potential contributions would be small compared to the paid efforts

More Related