1 / 16

HUMANOBS

HUMANOBS. Toward a programming paradigm for control systems with high levels of existential autonomy. Eric Nivel, Kristinn R. Thorisson Reykjavik University / Icelandic Institute for Intelligent Machines. AGI 2013 - Beijing – August 2013. Overview.

verne
Download Presentation

HUMANOBS

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. HUMANOBS Toward a programming paradigm for control systems with high levels of existential autonomy Eric Nivel, Kristinn R. Thorisson Reykjavik University / Icelandic Institute for Intelligent Machines AGI 2013 - Beijing – August 2013

  2. Overview > A G I: domain independence  scalability (in terms of complexity) > Natural intelligence vs manageable complexity > Constructivist approach: delegate to the system (some of) its own construction > Used for S1, an AERA based system, that learns socio- Communicative skills by observing people (HUMANOBS EU-funded FP7 project)

  3. Overview > Main characteristics of Replicode: - Based on a non-axiomatic logic: real-valued and time constrained. - Data-driven, computation based on pattern-matching. - Stateless executable code (models, composite states, programs). - No explicit ifs, loops, OR, AND. - All executable code run concurrently: massively parallel - Code can be an input for some other code. - Code can be active or inactive.

  4. Overview > Main characteristics of Replicode: - A kind of functional language, LISP-like syntax, not typed. - Data can be salient or not. - Data and code (objects) have a limited life time (resilience). • Once produced, objects cannot be modified. • Objects live in workspaces (groups), possibly in several of them. • Groups control the lifecycle and state of objects at various frequencies. - Extensible set of operators; hooks for custom C++ code (icpp_pgm).

  5. Dynamic Model Hierarchy > A model captures a causal relationship (deduction, i.e. prediction). > A model can thus be used to perform abductions (ex: sub-goaling). > A model is bidirectional and performs deductions and abductions concurrently. A(X,Z,W) B(X,Y,Z) M0 Forward: a  predicted b and iM0(x,z,w,y); Y can be a function of X, Z and W. Backward: goal b  sub-goal a; W can be a function of X, Y and Z Predicted b and sub-goal a are monitored, success of M0 is assessed in due time

  6. Dynamic Model Hierarchy > Indirect coupling / pattern affordances. M0: [A  B] M1: [B  C] M2: [C  D] M0 M1 M2 M3: [E  C] M4: [C  F] M5: [|G  C] M3 M4 M5 Forward: a  predicted b  predicted c  predicted d Backward: goal d  sub-goal c  sub-goal b  sub-goal a  sub-goal e  sub-goal |g

  7. Dynamic Model Hierarchy > Pre-conditions. iM0 = instance of M0, NOT M0 itself IF M0 fires (at some time), it will succeed M0: [A  B] M2 M1: [C  iM0] Pre-conditions (weak) - OR M1 M2: [|D  iM0] M0 M3: [E  |iM0] Pre-conditions (strong) - AND M3 M4: [|F  |iM0] M4 IF M0 fires (at some time), it will fail Execution of a model, success/failure thereof ARE REGULAR (INTERNAL) INPUTS.

  8. Dynamic Model Hierarchy > Post-conditions. M0: [A  B] WHEN M0 has fired (at some time) M6 M5: [iM0  C] M0 M6: [|iM0  D] WHEN M0 has not fired (at some time) M5 M15 M7: [iM12  iM0] M12 M10 M8: [iM13  |iM0] M7 Combinations M9: [|iM14  iM0] M0 M8 M10: [|iM15  |iM0] M9 M13 M14

  9. Dynamic Model Hierarchy • > Control hierarchy > Dynamic: models are built/deleted dynamically. predictions I/O goals

  10. Dynamic Model Hierarchy > Dynamic: models are activated accordingly to their success rate: under a threshold, no execution. > Inputs hold a confidence value (saliency): under a threshold, no input. > pred.cfd=input.cfd*modl.sr (likelyhood for the pred to be true). > goal.cfd=super-goal.cfd*model.sr (likelyhood for a goal to succeed).

  11. Dynamic Model Hierarchy > Given limited resources, only the paths consisting of the best models will be followed. I/O

  12. Dynamic Model Hierarchy > Drives and top-level models are hand-coded. > Drives are non-observable states. > Drives are re-generated dynamically (defined by the programmer). > Top-level models are given ways to satisfy drives. I/O drives top-level models learned models

  13. Dynamic Model Hierarchy > States: atomic or composite; constitute the patterns found in models. > States can be composed of other states  state hierarchy. > Reflectivity: internal operations are reflected as states. Composite states can encode concepts in an operational fashion. > In addition to a control hierarchy (procedural) we also have a concept (structural) hierarchy. A(X,Z,W) B(X,Y,Z) C(X,T) S0 A, B and C are synchronous states synchronous: hold within a common time interval

  14. Dynamic Model Hierarchy > Indirect coupling: models are not hardwired to each other. They are coupled via events in the workspace. > Pattern affordance. > Control hierarchy: affordances, pre- and post-conditions. > Dynamicity: models are added/deleted/activated continuouslsy. > Concept hierarchy: states encode concepts at different levels of specification.

  15. Logic > Real valued: confidence (not a probability) in [0,1]. > Time constrained: time interval [after, before[; bounds in µs. > Inference rules govern: - Deduction (forward chaining) - Abduction (backward chaining) - Induction - Commitment (resolution of simulation)

More Related