1 / 28

Common Reality

Common Reality. Towards a standardized interface mechanism. Outline. Rationale Proposal Broad Considerations Conceptual Schematic. Outline. Rationale Embodiment Push Architectural Comparisons Leverage Architectural Strengths Reusability Common Realities Proposal Conceptual Schematic

akio
Download Presentation

Common Reality

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. Common Reality Towards a standardized interface mechanism

  2. Outline • Rationale • Proposal • Broad Considerations • Conceptual Schematic

  3. Outline • Rationale • Embodiment Push • Architectural Comparisons • Leverage Architectural Strengths • Reusability • Common Realities • Proposal • Conceptual Schematic • Broad Considerations • Proposal Resources & Recommendations

  4. Embodiment push • As architecture designers and modelers we are increasingly finding ourselves integrating models with the real world • Computer interfaces • Sensor integration • Robotic devices • Solutions are often cobbled together • Task specific • Architecture specific

  5. Architectural Comparisons • As the range of modelable phenomena increases, we find ourselves comparing architectures • Same tasks - different (customized) realities • AMBER • PokerBot Challenge • Wouldn’t it be nice to have everyone on the same page?

  6. Leverage Architectural Strengths • Cognitive architectures are very good at what they are targeted towards • Often high-level cognition • Robotics and AI researchers can benefit from using these architectures for just that

  7. Reusability • If a CommonReality interface can be developed… • Modularity at the architectural level • Modularity at the device level • Freedom and flexibility to assemble solutions more rapidly and reliably

  8. Common Realities • The benefit for a standardized mechanism for interfacing reality is obvious • Plug’n Play for architectures • Standardized interface for sensor processing • One less DoF when comparing architectures • Makes decreasing DoFs significantly easier

  9. Outline • Rationale • Proposal • CommonReality Open Group • Working group composition • Broad Considerations • Conceptual Schematic • Proposal Resources & Recommendations

  10. Common Reality Open Group • Propose the formation of a working group to define a common interface • Following the Open Source egalitarian democratic model • Proposals are presented, discussed, & revised by the core working group • Adoption voting by the larger community • Focus on interface support for cognitive architectures (from the Psychological perspective)

  11. Working group composition • Open membership, representing: • Cognitive architecture developers • Modelers • Robotics engineers • Sensor engineers • etc.

  12. Outline • Rationale • Proposal • Broad Considerations • What constitutes reality? • Hardware & Software constraints • Time control • Reality parceling • Conceptual Schematic • Proposal Resources & Recommendations

  13. What constitutes reality? • The parceling of reality into discreet and manageable chunks for architectures is complex and often computationally intensive • Visual object detection • Spatial segmenting • Audio signal processing • Movement programming and control • Cognitive architectures rarely require knowledge of the nitty-gritty • Visual features • Semantic/syntactic content of audio streams

  14. However.. • As architectures seek to remove degrees of freedom.. • Reality parceling will need to adjust to increasing granularity

  15. Broad Considerations • Different theories & architectures may require different reality parceling schemes • Different architectures and configurations will have different temporal natures • Architectures & sensors often have different hardware (software) requirements

  16. Hardware & Software constraints • Architectures are not language agnostic • C/C++ • Lisp • Java • Sensors often have very specific hardware requirements • Custom ASICs • Intel • PowerPC • Video processing ASICs • Communication must be hardware and software agnostic • Communication Layer

  17. Time keeps of slipping.. • Different model applications require different time control • Bulk data runs require model controlled time (run as fast as possible) • Multiple models requiring accurate time control need shared time control • Simulation ‘reality’ may need to control time • Straight up real-time • Multiple Clock types • Shared (among models) • Real-time (pulled from the system / networked clock) • Private (controlled by a single thread of execution)

  18. Reality parceling • Different architectures will require different parceling schemes • Different interfaces will provide different schemes

  19. Outline • Rationale • Proposal • Broad Considerations • Conceptual Schematic • General Embodiment Model • Abstracted Embodiment Model • General Components • Proposal Resources & Recommendations

  20. Device Control Sensory Information Time Synchronization General Embodiment Model Cognitive Architecture Device

  21. Device Control Sensory Information Synchronization Abstracted Embodiment Model Architecture RealityInterface Device

  22. General Components Architecture Communication Layer RealityInterface AfferentEvent Manager Object Manager EfferentEvent Manager Time Manager Communication Layer Device

  23. Abstract Embodiment Model • Allows developers to focus on their side of the problem • Single device interface for multiple architectures • Architectures and devices can communicate across different hardware & software configurations

  24. Devil’s in the details • RealityInterface must be general enough to support • Symbolic (e.g. ACT-R, SOAR) • Subsymbolic (e.g. MINERVA, connectionist) • Communication Layer separates • Language specifics (e.g. Lisp, Java, C/C++) • Hardware details • Time control • Common to all architectures • Different execution goals require different time constraints • Precise time control (data generating models) • Real-time control • Hyper-time • Different time controllers • Device • Model/Architecture

  25. Outline • Rationale • Proposal • Broad Considerations • Conceptual Schematic • Proposal Resources & Recommendations • Functional Requirements • Division of Development • Resources

  26. Functional Requirements • Let’s get to brain-storming • What is actually needed? • Architectural side • Device side • Interface side • To jump start things, have a look at CROG-prototype.ppt

  27. Division of Development • Propose a reference RealityInterface implementation for each major language • Java (one exists based on the prototype previously mentioned) • C/C++ • Lisp • Reference implementation includes • RealityInterface components • Basic CommunicationLayers (TCP) • Generalized device launch & configuration tools

  28. Resources • CommonReality project on SourceForge • http://sourceforge.net/projects/commonreality/ • CVS • Forums • Mailing lists • Interested in participating? • Create a Sourceforge user account • Email me your account name to be added

More Related