Programming with Python. Part 3. Different Behavior Functions for Experiments 1-4 eJournal ISSN 2567-6466
Gerd Doeben-Henisch
October 18, 2017

1 Problem to be Solved 1
2 How to Program 2
2.1 Empty Behavior Function . . . . . . . . . . . . . . . . . . . . 2
2.2 Fixed Behavior Function . . . . . . . . . . . . . . . . . . . . . 7
2.3 Random Behavior Function . . . . . . . . . . . . . . . . . . . 10
2.4 Food-Intake Function . . . . . . . . . . . . . . . . . . . . . . . 11


According to the actual requirements we have to prepare 4 different
types of behavior functions

1 Problem to be Solved

In part 2 we have mentioned the following 4 types of behavior functions
which we need:
1. The behavior function phi of the actor is ’empty’  phi = 0. The actor
functions like an ’envelope’: you can see the body of the actor on the
screen, but his behavior depends completely from the inputs given by
a human person.
2. The behavior function  of the actor is driven by one, fixed rule  phi(i) = const. The actor will do always the same, independent from the environment.
3. The behavior function  of the actor is driven by a source of random
values; therefore the output is completely random phi(i) = random.
4. The behavior function  of the actor is driven by a source of random
value but simultaneously the actor has some simple memory  remembering the last n steps before finding food. Therefore the behavior
is partially random, partially directed depending from the distance
to the goal food:  phi : I  x IS —> IS  x O with internal states IS as
a simple memory which can collect data from the last n-many steps
before reaching the goal. If the memory  is not empty then it can
happen, that the actual input maps the actual memory-content and
then the memory gives the actor a ’direction’ for the next steps.

In this part 3 we will program the cases 1-3 and we will implement a
food-intake function which will increase the energy level again.

For more see the attached PDF-file.

For all the python sources see the attached ZIP-file.

Continue to part 4 (First Milestone)

Programming with Python. Part 2. Replacing console interactions by mouse-click events
eJournal ISSN 2567-6466

Gerd Doeben-Henisch



1 Problem to be Solved 1
2 How to Program 2
2.1 Continuation with Timer instead of Console Interaction; Quit . 2
2.2 Inserting an Actor by Mouse-Click . . . . . . . . . . . . . . . 3
2.3 Putting Things Together . . . . . . . . . . . . . . . . . . . . . 6


Taking the proposal from Part 1 for an environment-actor demo
and enhance it with replacing all console interactions with mouse-click
In this part 2 (see the attached PDF for Details) the last version ‚‘ will be improved by replacing all console interactions by mouse-clicks or by time-delay functions. There are also some minor improvements of the files and

How to Continue?

Continue with Part 3

Programming with Python. Part 1. A simple Actor-Environment Demo eJournal ISSN 2567-6466
Gerd Doeben-Henisch
October 14, 2017



1 Introduction 2
2 Python Context 2
2.1 Python Language Source . . . . . . . . . . . . . . . . . . . . 2
2.2 Simple Graphics Library . . . . . . . . . . . . . . . . . . . . . 3
2.3 Python Console . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Integrated Programming Environment . . . . . . . . . . . . . 4
2.4.1 PyCharm . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4.2 WinPython (With spyder and numpy) . . . . . . . . . . 6
3 Problem to be Solved 6
4 Programming with Python 8
4.1 Testing an Environment . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 A First Window . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2 Rectangles, Lines, Circles, Text-Labels . . . . . . . . 9
4.1.3 Producing a Grid . . . . . . . . . . . . . . . . . . . . . 10
4.1.4 Grid with Vertical Lines . . . . . . . . . . . . . . . . . 12
4.1.5 Grid with Vertical and Horizontal Lines . . . . . . . . . 14
4.1.6 Introduce Helper Functions . . . . . . . . . . . . . . . 15
4.2 Introducing Objects . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Introducing Actors . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 First Requirements for an Actor . . . . . . . . . . . . . 22
4.3.2 First Considerations How to Program . . . . . . . . . 23
4.3.3 Let an Actor Move: Environment . . . . . . . . . . . . 27
4.3.4 Let an Actor Move: Actor Self . . . . . . . . . . . . . . 37
4.3.5 The Final Main Procedure . . . . . . . . . . . . . . . 41
4.3.6 Final Helper Functions for the Environment . . . . . . 45
4.3.7 Final Helpfer Funtions for Actors . . . . . . . . . . . . 50
5 Close Up 54


What you see here is the content of the attached PDF.  The text is somehow a protocoll of an experiment to learn the programming language python from scratch. No pre-knowledge, no tools, no teachers! If you are in the same situation and you like to learn python since long, here you can enter and follow the steps.


Many years I opposed to learn python because in my view the language is really disgusting from the point of view of mathematics. But, one has to accept, that python has made its way in many areas including technology, science, and the arts. And because I needed urgently an acepptable software environment for all my theories and experiments there is sometimes the day of decision: you have to start or you can’t show many things.

There is another point: meanwhile I identified as main framework for our theories (which we are discussing on the combination of ubuntu + ros (robot operating system) + tensoflow. Here python is the main langauge besides C/C++. Furthermore  I detected many applications for our art projects, which are also strongly supported by python. Thus the motivation became stronger than my disgust about this quirky style of thinking.

In the attached PDF you can see how I battled through the python-jungle in 3 days producing a first outcome.

After these 3 days I would say, yes, python is a worthful tool to work with. I am convinced that we can solve most of our problems with it.

Therefore it is highly probable that you will find here more documents with python programs in the future. The idea is indeed to set up a local learning environment (LLE) which is small, flexible, portable,  and very powerful. It should enable really intelligent machines to help people, not to substitute people. The future will belong to new men-machine couplings.

CONTINUE with Part 2

EML ROS-Environment. Basic Ideas

EML ROS-Environment
Basic Ideas
eJournal ISSN 2567-6466

Gerd Doeben-Henisch

Oct-5, 2017



This text deals with the software ROS (Ros Operating System) as tool for the emerging-mind lab software framework. One main application will be for the Actor-Actor Interaction (AAI) paradigm of the project.

Taking the AAI theory as a first source for requirements we can infer the following requirements for useful simulation tools:

  1. AS: Built a mathematical graph for the actor story (AS). This will be called actor-story graph (ASG)
  2. ASSim: Built an actor story simulator which can read a actor-story graph (ASG) as input. 
  3. AM: Built actor models (AM) for selected actors.
  4. AMSim: Built a actor model simulator (AMSim) which can take actor models as inputs.
  5. ASWP: Built an actor software platform (ASWP) which can manage an actor story simulator with n-many distributed actor model simulators.
  6. TPs: Enable the software platform to allow defined test protocols (TPs) to check the behavior of AMSims with regard to a ASG.
  7. INTr: Enable the ASWP to allow interactions of human actors with AMSims

Depending from the problem to be solved there is a great variety of actor stories and actor models possible.

The same holds for possible hardware and programming tools.

In this text the selection of the software has a clear bias: we want to use software which fits to real world requirements too, not only to theoretical considerations. With this bias there it is a good working hypothesis to select the robot operating system (ROS) based on ubuntu 14.04 as an actor software platform (SWP). This software platform enables from the beginning distributed actor models (AMs) and test protocols (TPs). Depending from the way of programming one can state further that the ubuntu+ROS ASWP offers built-in simulation power for AMSims as well as ASSims.

What has to be done from scratch that is the definition and construction of ASs as well as AMs.

To learn all these concepts we will stepwise examine the robot operating system running on ubuntu-linux.

Helpful websites are the following ones:

  • ubuntu: or
  • ros:
  • linux tutorial(s):
  • python:
  • screen recorder:

A helpful book for ROS is that by the authors of the ROS: Quigley[QGS15]

Concepts meet Concepts

Having the platform ubuntu and ros under your fingertips we want to explore, whether this platform really can do the job we want to do.

Simulated Robots

Before we go into the details of the platform and the concepts there is an interesting idea presented in the book of Quigley et al.[QGS15], which offers a very general perspective.

Although the final goal of ROS is to operate real robots connected to human actors and different kinds of real systems the ROS can also support simulated robots. It is a strong point of ROS that it makes not too much a difference whether you are using only a software robot or a real robot. For simulations you need simulation environments presented to the expert in a graphical format. Generally you can connect many different such simulation systems with ROS. One powerful simulator with the name ‚gazebo‘ comes with the ros distribution. It is contained in the gazebo_ros package. In the book it is described as follows: „This package provides a Gazebo plugin module that allows bidirectional communication between Gazebo and ROS. Simulated sensor and physics data can stream from Gazebo to ROS, and actuator commands can stream from ROS back to Gazebo. In fact, by choosing consistent names and data types for these data streams, it is possible for Gazebo to exactly match the ROS API of a robot. When this is achieved, all of the robot software above the device-driver level can be run identically both on the real robot, and (after parameter tuning) in the simulator.“(see: Quigley (2015),p.94)

Thus for the goals of the AAI-theory this offers the perspective that one can translate the concepts of the AAI-theory into software concepts realized as simulations, which then can also be used for real world implementations.

AAI Graph

Within the AAI theory two basic concepts are the actor story (AS) and the actor model (AM).

The actor story describes the complete process of practicing a task within the space which is given by the problem statement of some stakeholder. There can be several tasks which have to be considered and there can be tasks in parallel or interrelated.

This set of tasks can be described with the aid of a mathematical graph with extended properties (for details see the AAI-theory at The nodes of such an AAI-graph represent the state of affairs at a certain moment t of time. These states of affairs are called situations or scenes. A scene is a collection of properties organized as subsets, which can be embedded representing hierarchies. Different kinds of actors are then different kinds of subsets of a scene. What can change a scene is either an event caused by the context of actors or by some action of an actor. Events or actions trigger therefore a change in the scene at time t and produce thereby a new state of affairs at some time t+x on a time line. Thus the connections between two scenes is an edge representing such an event or action. Every scene can have more than one edge going out and coming in. In the special case of a zero event or zero action no property is changing and the scene stays ‚unchanged‘. In this case the outgoing edge can represent an incoming edge too.

Before we discuss the concept of an actor model we will examine whether and how the concept of an AAI-graph can be supported by the ROS.

ROS Graph

The main conceptual property of ROS is the network of processes which can exchange messages.

Every such process is in ROS interpreted as a node in a graph, where the messages are seen as edges which can travel from every node to every other node. This is often called a peer to peer network. Typically a node is a POSIX conform process and the messages are representing TCP connections (cf. Quigley EtAl:2015:pp.9ff). Furthermore a node is organized as a kind of a framework called workspace. Inside of such a workspace you will find two different things: (i) a section with source code defining the behavior of this node and (ii) several kinds of other sections needed for the organization of the node within the network as well as for the software build-processes.

To realize the the communication between the nodes there exists a special process — a kind of a meta-node — called roscore, which allows the different ’normal‘ nodes to contact the roscore and become registered in the roscore for communication. Being registered a node can receive message from other nodes or send messages.

AAI Graph meets ROS Graph

The interesting question now is, whether and how the AAI-graph and the ROS-graph do match.

The answer is: they do match, but perhaps in a different way the reader may expect.

The main point is that the network of nodes, communicating with each other represent on a time line a sequence of different states of affairs.

At some time t on the time line we have a collection of nodes with certain properties. When a communication happens this can trigger some change in one of the nodes. In that case we have some time t+x where the properties in the collection of nodes have changed (or not, a special case).

Seen with the eyes of an AAI-theory the collection of nodes at some time t in the ROS network all together represent a situation, a scene, which represents a node in the AAI-graph. The different ROS-nodes are in the AAI-graph subsets of a AAI-scene representing possible actors. Every AAI-actor can have more subsets, representing a kind of a hierarchy. The ROS-messages are in the AAI-graph possible events or actions caused by AAI-actors. If such AAI-events or -actions change at least one property then an AAI-scene changes and generates by this a new AAI-node. Otherwise the AAI-scene continues. Because the properties of AAI-nodes can change the whole AAI-Graph can change. This corresponds well to the ROS-graph where nodes can be introduced during the process or can disappear; clearly ROS-nodes can also change properties while they are acting.

To be continued …. ‚Building a simple ROS-graph’….


[QGS15] Morgan Quigley, Brian Gerkey, and William D. Smart. Program-
ming Robots with ROS. O’Reilly Media, Inc., 1005 Gravenstein
Highway North, Sebastopol, CA 95472, 1 edition, 2015.


some background story

Gerd Doeben-Henisch



Some information about the motive behind this project; some historical remarks.


This relaunch of the eJournal (ISSN 2567-6458) is motivated by an international book project rewriting the ideas of systems engineering (SE), actor-actor interaction (AAI) as part of systems engineering, as well as intelligent machines (IM) as part of AAI. There is also an introductory part which talks explicitly about the implicit philosophical assumptions which underlie a systems engineering approach in general. This book is written embedded in a public process documented on the website.


While the above mentioned book develops a strong formal framework for all the mentioned topics, such a pure formal approach is not enough. The processes described in the book are intended real processes in real environments relying heavily on software. Therefore it is an equally important question which kind of software framework can help in the application of the theory. The following requirements are considered as being important for the development of the emerging-mind lab.

AAI Theory

As one can read on the uffmm-site a radical formal approach is applied there to describe the analysis phase of systems engineering as it is realized by an actor-actor interaction approach. But for the real work this is not enough, one needs for the practical (industrial) work in the end software tools which support the formal theory to do the real work.

Intelligent Machines

Intelligent machines are analysed in the book as actor models within actor stories. Thus models can only be used as real dynamic processes if they are translated into real software within real computers. And this should be done in accordance with the AAI-paradigm.

Local Learning Environments

There is a third requirement which stems from the context of education and experimental research.

Today everybody has a computer or a smart-phone to log into some network which provides lots of services from somewhere. The network as such also the services as such are usually not open for experimental usage. But in education as well as in research one needs complex settings and one needs open structures, which can be changed.

For this one needs a local learning environment which contains its own network server with different clients (computers, smart-phones, raspi, robots, and so on) which can have more smaller clients like sensor, actors etc.

Solution Candidates

Although the search for an optimal hardware and software environment has not yet finished we have two first interesting candidates as main part of the intended structure: It is (i) the robot operating system (ROS) (see: running on ubuntu (actually only on the long term version 14.04), and, with a different scope, (ii) the tensorflow framework (see:

How to Continue?

The next possible readings are:

  1. EML ROS-Environment. Basic Ideas
  2. Python Programming. Part 1. Simple Environment-Actor Demo


This is a completely new restart of the old emerging-mind website. It is intended as a working place for those people who want to establish software for learning systems in the full spectrum of live.

Emerging-mind lab is connected to the scientific workplace, where a new general theory is emerging comprising the topics:

The emerging-mind lab offers a software-environment to implement the ideas from and even more.

How to Continue?

Read the Background Story