Autor: Gerd Doeben-Henisch

PROGRAMMING WITH PYTHON ON UBUNTU. Part 1. Build the Environment

eJournal emerging-mind lab (EML)
ISSN 2567-6466
info@emerging-mind.org
Author: Gerd Doeben-Henisch
gerd@doeben-henisch.de

Abstract

After the description of how to use the python programming language under windows 10 starting from scratch in 6 posts we start here with some more posts dedicated to the question how to start programming
with python under linux using the distribution ubuntu 14.04. This distribution is selected because we will use later the ros (robotic operating system) as well as the tensorflow library.

Keywords: ubuntu 14.04, python 2, python 3, spyder

See for the details:

PDF

With a commenting Video

Programming with Python. Part 6. First Demo Extended

emerging-mind.org
eJournal ISSN 2567-6466
(info@emerging-mind.org)
Author: Gerd Doeben-Henisch
gerd@doeben-henisch.de

ZIP-SW

VIDEO

Abstract

Part 4 was the first Milestone. For details see that document. In part 5 only small modifications and extensions happened.

Modifying Control Window Calls

There is only one simple call to start the control window without any other functions, this is ctrlWinStart(). All other calls do operate on features of the control window.

Extending Control Options With Percentage of Objects

A new control feature has been introduced: asking for the percentage of objects to be placed in the environment: ctrlWinLocateAct(winC). This allows a number between 1-100. The percentage of food-objects is still kept fixed with ’nfood = 1′.

The Whole Story Now

  1. A 7 x 7 grid is offered with empty cells.
  2. The user is asked for the percentage of objects in the environment (nobj) which shall randomly be distributed (black cells).
  3. 1% of cells is randomly occupied by food (i.e. here one cell) (green cell).
  4. The start position of an actor (red circle) can be selected by pointing into the grid.
  5. The number of cycles can be entered how often the environment shall be repeat the event loop.
  6. The type of behavior function of the actor can be selected: manually (:= 0), fixed (:= 1) as well as random (:= 2). With option 1 or 2 the demo is running by its own. With option 0 you have to select the next direction manually by clicking into the grid.
  7. While the demo is running it reports the actual energy level of the actor as well as the actual ‚Time of the environment‘ (which corresponds closely to the number of cycles).
  8. If either the maximum number of cycles is reached or the energy of the actor is below 0 the application will stop and after clicking into the grid  vanishes from the screen.

Asking for Percentage of Objects

ae5-Control Window asking for Percentage of Obstacles in Environment
ae5-Control Window asking for Percentage of Obstacles in Environment

Asking for Number of Cycles

AE5 - Control Window Asking for Number of Cycles to Run
AE5 – Control Window Asking for Number of Cycles to Run

ASKING FOR POINTING INTO THE GRID TO LOCATE ACTOR

AE5 - Control Window askeds to point into Grid to locate the actor
AE5 – Control Window askeds to point into Grid to locate the actor

Showing Env With Obstacles and Food

AE5 - Control Window Showing Actual Distribution of Obstacles (black), Food (green), as well as an Actor (green)
AE5 – Control Window Showing Actual Distribution of Obstacles (black), Food (green), as well as an Actor (green)

Select Behavior Type

AE5 - Control Window asking for Wanted Behavior Type of Actor (0-2)
AE5 – Control Window asking for Wanted Behavior Type of Actor (0-2)

Final Stage

AE5 - windows shows Grid with final state
AE5 – windows shows Grid with final state
AE5 - Control Windows Comments Final Stage with no moe Energy for Actor
AE5 – Control Windows Comments Final Stage with no moe Energy for Actor

The Importance of Freedom and Creativity

Although this environment is very simple, it can demonstrate a lot of basic ‚verities‘. It shows directly the inappropriateness of a fixed behavior even in a static environment. This implies that a non-fixed behavior realized as a random behavior is in principle strong enough to find a solution (if there is any). Whether a solution is possible or not depends from the available time which in turn depends form the available energy.

If one interprets‚random behavior‘ as a behavior based on freedom and creativity then one has here a strong motivation that a society based on freedomand creativityhas (other ‚bad‘ factors neutralized) the best chances to master an unknown future.

How to Continue

You can continue with Part 1 ‚How to Program with Python under ubuntu 14.04?‘

Programming with Python. Part 5. From Windows to Linux

emerging-mind.org
eJournal ISSN 2567-6466
(info@emerging-mind.org)
Gerd Doeben-Henisch
gerd@doeben-henisch.de
October 20, 2017

In the parts 1-4 it has been explored how it is possible to program under Windows 10  in python a small test project within an  actor-anvironment framework. It worked.

In part 5 it will be tested, whether and how one can transfer the sources from part 4 to the platform ubuntu 14.04.

After some searching of different options it revealed to be very straightforward: open a linux console and enter the command:

sudo apt-get install spyder3

This installs the same spyder version as for Windows 10 including python 3.4.3 with all the libraries, including numpy. The only thing one has to do manually is to download again the graphics.py module from John Zelle (you can find it with google-search for a direct download).

Continue to part 6

Programming with Python. Part 4. First Demo complete

emerging-mind.org
eJournal ISSN 2567-6466
(info@emerging-mind.org)
Gerd Doeben-Henisch
gerd@doeben-henisch.de
October 20, 2017

PDF

ZIP-SW

1 First Milestone Reached

The basic idea from the beginning was to check whether it is possible to
program in python a simple actor-environment demo with a graphical user interface (GUI).

During the parts 1-3 it could be proved step wise that all the wanted
features could be realized.

Clearly the actual code is far from being elegant nor is he completely
explained. But everybody can inspect the code delivered as a ZIP-folder.

This first GUI-based demo contains the following features:

1. A 7 x 7 grid is offered with empty cells.
2. 20% are randomly occupied by obstacles (black cells).
3. 1% of cells is randomly occupied by food (i.e. here one cell) (green
cell).
4. The start position of an actor (red circle) can be selected by pointing
into the grid.
5. The number of cycles can be entered how often the environment shall
be repeat the event loop.
6. The type of behavior function of the actor can be selected: manually
(:= 0), fixed (:= 1) as well as random (:= 2). With option 1 or 2 the
demo is running by its own. With option 0 you have to select the next
direction manually by clicking into the grid.
7. While the demo is running it reports the actual energy level of the actor
as well as the actual ’Time of the environment’ (which corresponds
closely to the number of cycles).
8. If either the maximum number of cycles is reached or the energy of
the actor is below 0 the application will stop and after 10 s vanish from
the screen.

2 How to Continue

There are many options how to continue. Actually the following ones are
considered:

ACTOR-ENVIRONMENT FEATURES

1. Enhance the actual version with with e.g. offering the selection of
more parameters to be eligible.
2. Allow multiple actors simultaneously.
3. Allow the automatic repetition of a whole experiment over n-times.
4. Allow storing of results and statistical evaluations.
5. Start explorations of different behavior functions like genetic algorithms,
classifiers, reinforcement, learning similar to alpha go zero,
etc.
6. Enhance perceptual structures and motor patterns.
7. Check different cognitive architectures
8. Enable basic dialogues with the environment
9. …

COMPUTING FEATURES

1. Transfer the windows implementation on ubuntu 14.04 too.
2. Compare the different versions.
3. Integrate the actor-environment pattern within the ros-architecture
4. Allow real-world sensors and actors especially for robotics, for sound
art work, for picture art work, for sculpture art works as well as for text
art work)
5. Rewrite the actor-environment demo as a distributed process network.
6. Realize a first demo of a Local Learning Environment
7. …

Continue to part 5

Programming with Python. Part 3. Different Behavior Functions for Experiments 1-4

emerging-mind.org eJournal ISSN 2567-6466
(info@emerging-mind.org)
Gerd Doeben-Henisch
gerd@doeben-henisch.de
October 18, 2017

Contents
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

Abstract

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.
1
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

emerging-mind.org
eJournal ISSN 2567-6466
info@emerging-mind.org

Gerd Doeben-Henisch
gerd@doeben-henisch.de

PDF

SW-ZIP
CONTENT

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

OVERVIEW

Taking the proposal from Part 1 for an environment-actor demo
and enhance it with replacing all console interactions with mouse-click
events
In this part 2 (see the attached PDF for Details) the last version ‚gdh-win10.py‘ 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 environment.py and acctor.py.

How to Continue?

Continue with Part 3

Programming with Python. Part 1. A simple Actor-Environment Demo

emerging-mind.org eJournal ISSN 2567-6466
(info@emerging-mind.org)
Gerd Doeben-Henisch
gerd@doeben-henisch.de
October 14, 2017

PDF

SOFTWARE AS ZIP-FOLDER

Contents
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

BASIC IDEA

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.

STARTING WITH A REAL PROBLEM

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 uffmm.org) 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
emerging-mind.org
eJournal ISSN 2567-6466

Gerd Doeben-Henisch
info@emerging-mind.org
gerd@doeben-henisch.de

Oct-5, 2017

PDF

INTRODUCTION

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 uffmm.org 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: http://wiki.ros.org/indigo/Installation/Ubuntu or http://howtoubuntu.org/how-to-install-ubuntu-14-04-trusty-tahr
  • ros: http://wiki.ros.org/indigo
  • linux tutorial(s): http://www.ee.surrey.ac.uk/Teaching/Unix/index.html
  • python: https://docs.python.org/3.4/
  • screen recorder: http://www.maartenbaert.be/simplescreenrecorder/

A helpful book for ROS is that by the authors of the ROS: Quigley et.al.[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 et.al. (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 uffmm.org). 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’….

REFERENCES

[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.