Concept|Servo Automaton




Abstract


Cellular Automata (CA) are mathematical models for complex natural systems, consisting of a group of identical components who's behaviour is determined by local interactions with neighbouring components. Each component has a current state that is updated in a synchronous cycle along with the states of all other components. For this update, components use identical rules that determine the next state depending on one's own state and that of their neighbours.
Although these systems are defined by simplistic local rules, it has been shown that CA have the capacity to show complex behaviour[1] . Stephen Wolfram has directed much attention to the use of CA in modelling as well as the mathematical analysis thereof. One of his findings is that CA fall into four basic behaviour classes that can be distinguished both qualitatively and mathematically[2] . This project uses a three-piece modular robotic installation to enact these different classes of CA behaviour in physical space.

Concept

The project really has three main keystones: modularity, physical communication through buttons and locally interacting robots.

Modularity in build and code

The robotic system consists of three identical components that can be attached and detached if so desired. This has proved incredibly beneficial during the development of individual behaviour programs. Because each component can be detached and individually programmed, working in parallel with a group of three contributors becomes possible and overal development time is kept within limits.

This modular approach in the physical build is also reflected in the main code of the program. A strong object oriented programming (OOP) approach is taken for the implementation of the basic functionality of board, fingers and buttons. These different types of objects are implemented as separate classes with their own specific methods and internal data structures. Overal the OOP approach lends itself to improved flexibility and reusability in development. The main advantage of using objects in code though is the way this view is analogous to how we usually tend to think about the world around us. Objects in the world, such as a robotic arms, have specific features and allow certain actions to be performed on them.

Because CA lends itself perfectly to such an object based approach, the CA framework is also implemented as such.

Machines Pressing Buttons

It was clear quite early that we all liked to work around the idea of having several components communicating between each other. Because we are building a physical system we have chosen to have also the interactions mediated in physical space. The idea of having robotic fingers pressing each other's buttons appealed strongly and we decided to construct the installation so that each of the three components has a button appropriated to it. This sense of ownership is reflected in the object oriented code where each instance of class Finger has a instance of class Button assigned to it. The idea of objects 'owning' other objects adds to the sense of autonomy of the components individually and the system as a whole.

Looking at Neighbours

complex global behaviour emerges from local interaction

The central reason to use the states changes of CA as inspiration of the behaviour of the robotic system is their link to the simulation of natural systems and their use in Artificial Life. The characteristics of emergence of complex global behaviour from simple local interactions have made CA a subject studied by many researchers from different fields like biology, physics and mathematics. The particular feature of CA converging to attractor states gives the systems the capacity of self-organisation. It is these attractor states that distiguish the different classes of CA rules. Wolfram distinguishes four classes for each of which an example development is included:

Class 1 behaviour converges to a stable homogeneous attractor. After some number of updates, all components in the system have the same state.
Screen_shot_2012-05-07_at_13.02.42_.png
Class 2 behaviour converges to a stable spatially periodic or periodic attractor. After some number of updates, components stay in the same state, with several state values present or shows a periodic behaviour in space and time, such that a sequence of states is repeated with a steady period.

Screen_shot_2012-05-07_at_13.03.29_.png
Screen_shot_2012-05-07_at_13.04.32_.png

Class 3 behaviour converges to a chaotic pattern. The only way of algorithmically predicting future states from initial states is to simulate the complete sequence of intermediate states.
Screen_shot_2012-05-07_at_13.04.04_.png
Class 4 behaviour leads to complex localized structures, sometimes long lived. These structures are also not efficiently predictable.

Issues encountered

Hardware

  • What buttons to use? We hacked 3 computer mice for pus from mouse, but ended up using bought push buttons as they were better in size
  • How to get all servos attached? We extended cables using shrink wrap
  • How to design a finger that looks similar to a human finger? We studied the anatomy of our own hands.

Software

  • How to get signals from push buttons into urbiscript? buttons -> arduino -> serial -> processing -> network port on localhost -> urbiscript
  • How to implement a object oriented CA system? Written OO program in Python.
  • How to connect Python to Urbi? Used network via different port on localhost.
  • Arduino stops communicating with Processing?! Switch usb ports...?!

Extensions

The biggest extension I would like to make is in the physical build of the project. At the moment the simple components lead to a difficult dichotomy. Modelling each entire finger as a CA component yield a total number of 3 components. This state space has a size of 2^3 = 8 possible sates which is to small to enact class 4 chaotic behaviour. From an initial state it takes at most 6 update iterations to reach the initial state and the behaviour thus collapses in class 3 behaviour with a period of 6. The same rules applied to a CA with a larger number of components however can lead to chaotic behaviour (minimal 6 cells are necessary). Because of the moluarity, an extension to more components is very feasable.

Because three components limits the complexity of the automaton, each robotic finger could be split up in three servos that function as seperate components. This would mean ideally that each of the components has its own button to set the startstate of the finger. Further issues with this design are that the components are no longer identical and that its far from trivial how to model the components in 1-dimensional circular CA.

Hardware|Construction

DSCN6888.jpg
DSCN6891.jpgDSCN6895.jpg

DSCN6896.jpgDSCN6897.jpgDSCN6898.jpgDSCN6899.jpgDSCN6900.jpg

DSCN6901.jpgDSCN6903.jpg

See this documentation section for a detail overview of the different steps in the building process per week.

Software|Code

I developed the Board, Finger and Button classes in canCanBot.u, from where the three of us went our own way. I chose to implement the CA behaviour in Python because of its flexibility, reusability and speed and used a socket connection for the communication from Python to Urbi. On the Python end, users are presented with an interactive interface and can choose different commands to control the robot.
Screen_shot_2012-04-24_at_08.01.01_.png
; Python file with CA and Cell classes for Cellular Automata behaviour modelling and analysis
; Main urbiScript program for finger movements, containing classes for Board, Finer and Button
; Processing sketch to pass info from Processing via socket connection to Urbi
; Arduino sketch to receive button signals via serial and send them to Processing via socket connection
  1. ^ S. Wolfram. Statistical mechanics of cellular automata. Reviews of modern physics, 55(3):601, 1983.
    http://www.ifsc.usp.br/~lattice/artigo-wolfram-cellular-autom.pdf
  2. ^ S. Wolfram. Universality and complexity in cellular automata. Physica D: Nonlinear Phenomena, 10(1):1–35, 1984.
    http://www.bio.txstate.edu/~schwinn/Modelling/Lecture%2011/Wolfram_84.pdf