Toward a Programming Paradigm for Autonomous Control Systems

This article discusses a constructivist approach to programming autonomous control systems. The authors propose a delegate system for the construction of an intelligent machine, using the example of the HUMANOBS project. They argue that this approach has benefits in terms of scalability and flexibility.

Uploaded on Jun 01, 2023 | 0 Views
rosvi

About Toward a Programming Paradigm for Autonomous Control Systems

PowerPoint presentation about 'Toward a Programming Paradigm for Autonomous Control Systems'. This presentation describes the topic on This article discusses a constructivist approach to programming autonomous control systems. The authors propose a delegate system for the construction of an intelligent machine, using the example of the HUMANOBS project. They argue that this approach has benefits in terms of scalability and flexibility.. The key topics included in this slideshow are AGI, autonomy, constructivism, programming, scalability,. Download this presentation absolutely free.

Presentation Transcript

1. HUMANOBS AGI 2013 - Beijing August 2013 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

2. > 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) Overview

3. > 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. Overview

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) 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 M0

6. Dynamic Model Hierarchy M0: [A B] M1: [B C] M2: [C D] M3: [E C] M4: [C F] 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 > Indirect coupling / pattern affordances. M5: [|G C] M0 M1 M2 M3 M4 M5

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

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

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

10. > 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). Dynamic Model Hierarchy

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

12. > 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. Dynamic Model Hierarchy I/O drives top-level models learned models

13. > 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. Dynamic Model 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)