Robotic consciousness:

Evaluation of a proposal

Daniela López De Luise1, Nelson Biedma1, Lucas Martín Rancez1, Leonardo Isoba1 and
David Trejo Pizzo1
CI2S Labs, Pringles 10, Buenos Aires, Argentina [email protected]
Keyword: Autonomous Mobile Robots, Consciousness, Indoor Mobile Robot.

Abstract: Autonomous mobile robots require efficient control of their movement. This paper
focuses on a prototype implementing a consciousness model for autonomous
mobile robots. The prototype is named MARCOS (Movement of Autonomous
Robotics Codelet System). Here is an in-depth analysis of this secondary controller
that complements the main close-loop controller providing complex information
about the current robot status, and suggesting alternative actions. This paper
describes the MARCOS prototype and its conscious subsystem, as well as statistics
on how Concepts can model real-world indoor environments.

1 INTRODUCTION
Mobile robots may be studied in outdoor or indoor environments. This paper describes part of an
indoor mobile robot prototype named MARCOS (Movement of Autonomous Robotics Codelet System).
It uses Concept Learning (based on Conscious technology) to process several movement parameters.
The main goal of the MARCOS module is to provide the robot’s close-loop controller with
recommendations about which commands should be performed next. Because autonomous mobile
robots must navigate in dynamic environments, they require a large collection of environmental
information, efficient storage and good processing capabilities.
In the following sections, there is a description of the basic features of the Concept Model (section 2),
a general overview of the problem solving strategy used by MARCOS (section 3), the benefits of
working with MARCOS (section 4), and the status of the implementation and future work (section 5).

2 THE CONCEPT MODEL

MARCOS is a prototype of a homonym project. It uses CoFram, a subsystem that aims to be
an implementation of a Conscious Model (Baars, 1998) (Baars and Franklin, 2003)
(Baddeley and Hitch, 1974) (A. H.Varela and E.Rosch, 1991) (S. Franklin andVentura,2005)
(S.A. SlomanandKeil,1999).
CoFram was inspired by LIDA(Franklin and Patterson, 2006) (Baars and Franklin, 2009) and
FLEXO (Vanschoren, 2004). It contains some of their functionalities, but there is an
important difference with them: CoFram is not intended to be a concrete conscious model,
rather a framework for designing conscious models according to specific problems. Artifacts
are components of a meta-model framework. This meta-model was used to define a specific
model that let, for example, a robot move around even with basic abilities.

3 MARCOS PROTOTYPE
This paper focuses on MARCOS, which is an implementation of CoFram for an autonomous
indoor mobile robot adviser with obstacle Conceptualization for dynamic environments (H.
Zendera and Burgardb) (Barsalou, 1999) (Glenberg, 1997) (A. Baddeleyand Aggleton,
2001).

This project contributes to the field as follows:

• The project applies Conceptual Learning theories to robotics. One goal is to evaluate
 statistical information about the robots performance using such implementations.
• The model enables a simple robot to adapt itself to controlled dynamic
environments. The robot calculates paths to certain targets.

3.1 Architecture

The architecture has a dual-loop feedback system: one for immediate decisions (the RTC, or
Real Time Controller) and the other for middle to long-term strategies (the RTA, or Robot
Task Adviser).

3.1.1 Real Time Controller (RTC)

The RTC is involved in the direct communication with sensors. It aims to:
• Communicate the relevant sensor data to the RTA.
• Send commands to the robot’s engines.
• Take quick decisions for risky events.
If it is required a prompt response, the RTC may ignore the RTA commands and execute
some basic movements, for example to avoid collisions.

Figure 1: Close-loop algorithm

The RTC is a typical close-loop algorithm as in Fig 1. Mobile Robot Localization is

commonly addressed using laser, ultrasonic, magnetic or other sensory based information.
The information from these sensors is used to manage the environment and to determine
the robot’s position using a suitable algorithm. It is the duty of the RTC (Real Time
Controller) to manage data from sensors. The current robot configuration has few devices,
because the focus of the prototype is on the behavior analysis and global performance of
the CoFram model 2. Due to this configuration flexibility, the RTA (Robot Task Adviser) is
complex, in order to compensate all the extra information required to work properly.
As the MARCOS prototype (section 3) has been implemented for indoor environments (to
simplify the localization problem), the MARCOS project uses just ultrasonic technology. The
ultrasonic sensors used by MARCOS receive transmission streams to obtain the distance
between the sensor and an obstacle. With that information, MARCOS updates its world map
with the obstacles found.

3.1.2 Robot Task Adviser (RTA)

The RTA is intended for advanced adaptive behaviors. It is responsible for the following
tasks:
• Fast recognition of known objects: The environment contains several objects which
are physically detected and mapped against previously learned Concepts.
Additionally, they can be grouped into categories. Examples of categories are
 targetable, forgettable, etc. This way, targetable objects can have specific Concepts
associated, and therefore distinct logical treatments.
• Creation of a dynamic world map: The robot builds a virtual map as it learns about
the objects in the environment. This map is used for location and to build paths to
the goals.
• Construction and submission of recommendations to the RTC: With all the
information MARCOS, can create complex strategies to achieve its targets. Then
reduces that strategy into commands that are designed to be used by the RTC.

Those task gives to MARCOS the ability to:

1. Recognize learned obstacles: It finds obstacles physically similar to previously

encountered ones. To do this, it is important to define similarity metrics.

2. Recognize new obstacles: Unknown obstacles are objects that cannot be recognized. In
these situations, MARCOS can provide specific advices to the robot.

3. Recognize dangerous environments: Environment can be very complex(e.g., because of

people and other machines moving around). The prototype can process as dangerous
any unknown object.

4. Processing and learning based on experience: Data from the environment and robot’s
Concepts optimize the robots behavior by updating its dynamic knowledge database.

5. Define new actions: MARCOS can be trained to detect special situations and to perform
low priority commands (akin to suggestions) to the RTC.

3.2 Technical overview

The implementation of MARCOS currently requires Java, a minimum of 50 Mb of hard disk
storage and, at least a 1.2 GHz processor. The overall architecture of the MARCOS
prototype can be seen in Fig 2.

Figure 2: MARCOS global architecture.

Software was designed with several Object Oriented Design Patterns to provide the source
code with flexibility and readability. The robot is a LEGO Mindstorm NXT, with LEJOS 6.0.
connected to the Real Time Controller (RTC) which interacts with MARCOS.

3.3 MARCOS Workflow

To achieve MARCOS functions, the first step is to activate the Concepts that model initial
knowledge about the problem. That is the Genetic Knowledge of MARCOS, a group of
predefined Concepts that includes the targets, the initial axis position, etc.
The RTC (section 3.1.1) starts the lifecycle and notifies MARCOS about its presence.
When the robot starts, sensor streams are sent to the RTC, and are preprocessed looking
for risk situations and then pass the information to MARCOS. When the robot sends a data-
stream to RTC, it answers after a short time with a command to the robot, and sends data
to MARCOS.
When MARCOS detects a certain obstacle, it determines the type of Concept
corresponding to the obstacle. If there is no Concept for the obstacle, it inserts a new
Concept and returns a meta-command denoting the obstacle as an unknown object, and
assigning it a previously deaned action (e.g., elude it). Along with this, MARCOS calculates a
number indicating the relevance of the RTA suggestion (section 3.1.2). In the case of a
known Concept, MARCOS uses available information and related Concepts to select the best
meta-command to be sent. RTC eventually receives the meta-command. Using the meta-
command and the refreshed environment information, the RTC will decide whether or not to
change the robot’s behavior.
Fig 3 shows an overview of the main subsystems. The diagram shows main components
of CoFram with dashed lines.

Figure 3: MARCOS workflow.

Solid lines indicate which components belong to the derived MARCOS robot
implementation. MARCOS uses a set of specialized functionalities that are needed for an
autonomous-mobile robot and are not part of the CoFram framework (section 2). Percepts
are created from the meta-data sent by the RTC.
Data goes through the MARCOS input interface and enters the Workspace. The
Workspace represents a collection of Concepts. Inside the Workspace, the Concepts are
grouped by Workplanes. The Workspace is first populated with Percepts, which are unique
Conceptual information directly associated with the information coming into the system,
sensors data for example (Barsalou, 1999).
The Workspace Evaluator will select the best Workplane and push it into a pile. The
Queue Evaluator pops the best Workplane and extracts the proper information from it to
feed to the MARCOS output interface. The CoFram Evaluator is a general purpose
comparator that was defined as the Workspace Evaluator. To perform these comparisons, a
structure like java interface Comparable is used and implemented. Although it uses
functions instead of items for the comparison.
MARCOS also has small agents called Codelets. The task of the Codelets is to handle
Concepts in order to achieve the robot’s objectives. The Codelets elaborate strategies and
new derivation of the current strategies. Codelet activation (i.e. execution) follows the same
principles as in LIDA and FLEXO: probability is used to rank Codelets in a cluster of possible
codelets named Coderack. The Codelet Scheduler will manage the general activation
approach for all Codelets. However Codelets are not handled directly, rather they are
categorized and handled in sets or categories. It is expected that any specific model could
define sets of the appropriate size, ranging from one to many Codelets. There is another
Scheduler, the Coderack Scheduler, which is only present in CoFram and serves as an
interactive tool to allow incremental design in parallel with the working model. If the model
detects an unknown Concept using a threshold and similarity criteria, the Environment
Adaptation Manager (EAM) will detect it and deploy tools to extend the current model.
Perhaps one of the most relevant characteristic of CoFram is the concept of distance.
Percept properties are those aspects of percepts that need regular updating. In FLEXO, all
percepts in a workspace should have the same properties, to provide a means for
comparing them. In CoFram, comparators must be defined in every case to overload the
default comparison criteria. In this way, every specific model can have its own metrics to
evaluate relevance and distance between percepts and Concepts. The Workspace Evaluator
is the kernel of these metrics.

Figure 4: The general CoFram workflow.

Codelet creates a special Concept to alert the Environment Adaptation Manager, or EAM
(see Fig 4), when new external knowledge is required (which will eventually require an
operator interaction). This is one of the main artifacts of that CoFram metamodel
framework that is not defined in LIDA, IDA, or FLEXO. Note that even when the Concept is
not totally recognized, the model will keep working, replacing it with the closest current
Concept. EAM is a general purpose module that also provides tools for issues that are
specific to the current model (i.e. MARCOS), such as sampling parameters, mapping tasks
to execution threads, accelerating Codelets according to the current devices being used,
types of world-map, etc.
There are also two knowledge databases: one for the short term knowledge and another
for the long term knowledge. Information is uploaded from the former during initialization of
the Codelets and Workplanes. Later it is used for off-line activities and for statistical
evaluations.
MARCOS performs a very basic data processing and submits information to the kernel.
Then it activates CoFram functionalities to let it translate Concepts (i.e., receiving real world
information and gathering knowledge about obstacles), perform complementary
information managing. MARCOS builds an internal map within its local dynamic knowledge
database, and performs proper updates and makes decisions about the robot activity. The
main storage of MARCOS is its dynamic knowledge database, which holds key information
on life cycle management and specific data to improve performance. Unlike
implementations such as Navi-Gates (R. Knotts and Morris, 2007), the global architecture
splits the controller into levels of processing. This way, RTC can perform its tasks
independently (with or without RTA).
CoFram is not just an adaptation of previous conscious theories, but a new modeling
framework for consciousness. It does not mimic human brain activities. CoFram defines a
set of basic artifacts to provide assistance and repetition to the modeling process. In this
new model, patterns are Concepts handled by Codelets with a specific task inside a
Coderack (a set of small agents each having a very specific portion of code). With
autonomous mobile robots, real time answers require fast processing of external
information, and critical signals must be processed with a specific workflow that does not
exist in original conscious models. As a consequence of the learning process, Concepts
could be modified for certain situations. In this model, the recognized patterns may be not
only for external objects but also for internal ones.

4 MARCOS PERFORMANCE TESTS

This section describes tests performed with the current MARCOS prototype, several
statistics and characteristics of the controller behavior.

4.1 Tests description

The four tests were performed using the same map (see Fig. 5). The black dots are
obstacles. This map’s width is 800cm and its height is 600cm. The conditions for tests were:
1. The same starting position in the map.
2. The robot has to reach the opposite side of the map.
3. The robot should avoid all obstacles.

There are also some considerations:

• The MARCOS knowledge was cleared after every test, but the Java VM memory cached
some tasks, speeding-up certain processes.
• The world-map is never pre-fetched to MARCOS, only the coordinates of the target,
relative to the initial position of the robot
 Figure 5: The world-map used for testing

• There is no time limit during the test.

• The project has an RTC but its emergency artifacts were disabled to isolate the MARCOS
behavior. RTC only feeds the sensor information to MARCOS and executes MARCOS
commands.

Figure 6: Test traces.

1. First Run
The first execution shows interesting behaviors (see Fig. 6). The black line is the robot trace.
The red marks represent obstacles. Only one obstacle is detected by MARCOS but, as the
obstacle is not in the robot´s way, MARCOS doesn’t need to modify the path. Remarks:
• The trace is not straight to the destination. This is due to the strategies proposed are
not yet tuned to depend on the robot’s location/status.
• The path is biased by the number of proposed strategies, because the ability of
MARCOS to propose strategies was restricted by a parameter.
• At the beginning of the trace (see bottom of Fig. 3) a random behavior is shown. This
 is a consequence of the low level of knowledge about the environment. These
actions will improve with the help of the long-term memory (deactivated for these
tests).

2. Second Run
The second execution displayed on Fig. 6 confirms the observations shown in section
5.1. Four obstacles were found and avoided without losing performance on the trace.
This test allows other considerations:
• Sometimes the robot goes against the target direction. This is due to the limitation
of the amount of Strategies that can be proposed.
• Some of the robot’s turns are very sharp, because the winner strategies are biased
to save time.

3. Third Run
As shown in the Fig.6, in the third test, against the previous tests, the robot goes almost
straight and most of the rotations are very soft. Three obstacles are found and the robot
successfully avoids them without losing performance over the full path.

4. Fourth Run
The Fig.6 shows the trace of the last of the test. On this path only one obstacle is found
but MARCOS ignores it because it is not on the robots path. This path is pretty straight
until near the end, where the best proposed Strategy was to turn slightly against the
target. As stated before, the use of more complex statistics and previous knowledge will
certainly improve this behavior.

4.2 Log Analysis

The MARCOS prototype records actions for later analysis. The logs used for this paper are
limited to the most relevant data of this test cases

Figure 7: Codelets execution (vertical axis) amount against the time-line (horizontal axis).

1. Time to target: MARCOS is a multi-threaded system. The CPU and RAM memory usage
affect the performance. These differences can be observed in Fig. 7. There is a big
difference between the first timing run and the rest. This can be explained by the fact that
Java is able to enhance recently executed tasks.
 Table 1: Proposal Requests discarded by the lack of information.

2. Initial uncertainty: MARCOS builds almost all of the knowledge dynamically from the
sensors information and from previous knowledge. Whenever MARCOS starts from scratch,
the knowledge databases are empty and MARCOS cannot generate best Strategies. The
table 1 shows consequences of this state of uncertainty. Only 10% of the Strategies
requested by CoFram are discarded, but it is expected to improve with better order of the
initial execution and adjusted codelets.

Figure 8: Codelets execution (Translation Strategies) proposed.

Figure 9: Codelets execution (Rotations Strategies) proposed.

3. Proposed Strategies' Types: The limited set of Strategies types available just propose
basic translations and rotations (see Fig.8 and Fig. 9). Not all of them are necessary
executed. Graphic 10 shows that a similar number of rotations and translations are
proposed.
 Figure 10: Comparison between translations and rotations proposed.

5 FUTURE WORK
The current implementation is minimal and has to be considered as a starting point of study for
Concept Models applied to robotics. As the result of these studies, future implementations will
consider internal tuned statistics that will allow MARCOS to better selection of strategies.
RFID technology is reserved for a future implementation that will solve the localization problem
more efficiently, with a higher update rate, better accuracy and scalability at a lower price
(Gutmann and Fox, 2002). It will be evaluated also additional video and sound information with
RF (Radio Frequency) and ultrasonic technologies, such as RFID, ZigBee, wireless devices (J. B.
Hayet and Devy, 2002) and LaserTechnology (D. Lecking and Wagner, 2008).
Although the prototype is complete, there remains to implement better codelets and
Concepts to optimize robot performance and alternative hardware configurations.
There remains the implementation of activities such as lift, run, and jump to complement the
existing activities (advance, rotate and stop). Other extensions may be obsolescence and
past/future consciousness, improved object/obstacle recognition, additional knowledge about
the standard abilities in the robot (e.g., its ability avoid obstacles and threats) and the
surroundings (i.e., types of obstacles and the properties of such obstacles).
Currently, the project is adding more sensors to the hardware that will allow MARCOS to
have more information about the environment and about the objects in it. With this,
MARCOS can perform more complex tasks, for example move different objects from one
place to another or to handle leveled surfaces.
It will also be considered hardware localization on the robot to release MARCOS from this
task (whenever the hardware allows this), releasing more memory and CPU to handle more
complex tasks. Traditional localization in places such as factory buildings and halls, usually
involves
Processing a set of events and facts, such as the location of natural landmarks, walls, and
dynamic obstacles. There are several approaches for solving localization problems (D.
Lecking andWagner, 2008) (S.Kolski and Siegwart, 2006) (C. Eberst and Christensen, 2000).
The MARCOS architecture was developed to accomplish this by Concept handling.

REFERENCES

A. Baddeley, M. C. and Aggleton, J. (2001). Sensory-perceptual episodic memory and its context:
Autobiographical memory. In Episodic Memory, Oxford. Oxford University Press.
A. H. Varela, E. T. and E.Rosch (1991). The Embodied Mind: Cognitive Science and Human Experience.
MIT Press, Cambridge.
Baars, B. J. (1998). A Cognitive Theory of Consciousness. Cambridge University Press, Cambridge.
Baars, B. J. and Franklin, S. (2003). How conscious experience and working memory interact. In
Trends in Cognitive Science.
Baars, B. J. and Franklin, S. (2009). Consciousness is computational: The lida model of global
workspace theory. In International Journal of Machine Consciousness.
Baddeley, A. D. and Hitch, G. (1974). The psychology of learning and motivation: Advances in
research and theory. Working memory. Academic Press,NewYork.
Barsalou, L. W. (1999). Perceptual symbol systems. In Behavioral and Brain Sciences.
C. Eberst, M. and Christensen, H. (2000). Vision-based door-traversal for autonomous mobile robots.
inst. for real-time computer systems. In Proc. 2000 IEEE/ RSJ International Conference on
Intelligent Robots and Systems, Munchen.
D. Lecking,O. and Wagner,B. (2008). Localizationina wide range of industrial environments using
relative 3d ceiling features. emerging technologies and factory automation. In IEEE International
Conference on ETFA 2008.
Franklin,S. and Patterson,F.G. (2006). The lida architecture: Adding new modes of learning to an
intelligent, autonomous, software agent. In Integrated Design and Process Technology.
Glenberg, A. M. (1997). What memory is for. In Behavioral and Brain Sciences.
Gutmann, J. S. and Fox, D. (2002). An experimental comparison of localization methods continued. In
IEEE/RSJ International Conference on Intelligent Robots and Systems.
H. Zendera, O. Martnez Mozosb, P.J.G.K.and Burgardb, W., J.B. Hayet, F.L.andDevy, M. (2002).Avisual
landmark framework for indoor mobile robot navigation. In IEEE International Conference on
Robotics and Automation.
R. Knotts, I. R. N. and Morris, R. C. (2007). NaviGates: A Benchmark for Indoor Navigation.ACE
publications.
S.A. Sloman,R.W.andKeil, F. (1999). Cognitivearchitecture. In The MIT Encyclopedia of Cognitive
Science, Cambridge. MIT Press.
S. Franklin, B.J. Baars, U.R. And Ventura, M. (2005). The role of consciousness in memory. In Brains,
Minds and Media.
S.Kolski,D. ferguson,M.B. and Siegwart,R. (2006). Autonomous driving in structured and unstructured
environments. In IEEE Intelligent Vehicles Symposium.
Vanschoren,J.(2004). Fluid concept architecture:Acritical evaluatione. (cw2005). [m9918118].