INCORPORATING AN AIBO ROBOT INTO THE PEIS ECOLOGY FRAMEWORK

Document Sample
INCORPORATING AN AIBO ROBOT INTO THE PEIS ECOLOGY FRAMEWORK Powered By Docstoc
					                           Examensarbete 20 poäng D-nivå

INCORPORATING AN AIBO ROBOT INTO
  THE PEIS ECOLOGY FRAMEWORK
                           Reg.kod: Oru-Te-AUT067-Mag101/06

                                       Daniel Offrell


                           Automatiseringsprogrammet 160 p

                                  Örebro vårterminen 2006




Examinator: Boyko Iliev


Incorporating an AIBO Robot into the PEIS




            Örebro universitet                              Örebro University
       Institutionen för teknik                             Department of technology
                 701 82 Örebro                              SE-701 82 Örebro, Sweden
  Daniel Offrell                                                         20P Examensrapport
  Magister Automatisering 160P

Abstract
   The goal of this project has been to enable the incorporation of an AIBO robot into the
intelligent computer network called PEIS by converting existing software to function on
AIBO’s operating system. This report introduces you to AIBO and the PEIS-Ecology and
follows the work on learning how to use the programming tools for AIBO and what had
to be done to convert the software that runs the PEIS.



   Målet för det här projektet var att inkorporera en AIBO-robot i det intelligenta
datanätverket PEIS genom att konvertera den befintliga mjukvaran så att en fungerar i
AIBO’s operativsystem. Den här rapporten beskriver AIBO och PEIS-Ecology och följer
arbetet med att lära mig använda programmeringsverktyget för AIBO och vad som
behövde göras för att konvertera PEIS’s mjukvara.




                                                                                    1(26)
Daniel Offrell                                                                                                               20P Examensrapport
Magister Automatisering 160P

INDEX

1      INTRODUCTION.......................................................................................................................... 3
    1.1         PROJECT OBJECTIVES ............................................................................................................... 3
    1.2         METHODOLOGY ....................................................................................................................... 4
    1.3         OUTLINE OF THIS DOCUMENT .................................................................................................. 4
2      BACKGROUND ............................................................................................................................ 4
    2.1     ABOUT AIBO .......................................................................................................................... 4
    2.2     HARDWARE ............................................................................................................................. 5
    2.3     OPEN-R.................................................................................................................................. 5
       2.3.1 Object Messaging .............................................................................................................. 6
    2.4     PEIS-ECOLOGY ....................................................................................................................... 7
       2.4.1 Vision ................................................................................................................................. 7
       2.4.2 Architecture ....................................................................................................................... 8
       2.4.3 Test bed ............................................................................................................................ 10
3      OVERVIEW OF THE PROTOTYPE ....................................................................................... 11

4      OBJECTS IN THE PROTOTYPE ............................................................................................. 12
    4.1     P2P........................................................................................................................................ 12
       4.1.1 Porting of the PEIS-kernel............................................................................................... 12
       4.1.2 Interface ........................................................................................................................... 12
       4.1.3 RecBuff - my sockets ........................................................................................................ 13
    4.2     UDPCOMM............................................................................................................................ 14
       4.2.1 Wireless communication in OPEN-R ............................................................................... 14
    4.3     IMAGEOBSERVER .................................................................................................................. 16
5      ISSUES WITH PORTING OF THE PEIS-KERNEL .............................................................. 16
    5.1         IP COMMUNICATION .............................................................................................................. 16
    5.2         TESTING ................................................................................................................................ 17
6      DISCUSSION AND CONCLUSION.......................................................................................... 20
    6.1         ACHIEVED ............................................................................................................................. 20
    6.2         PROBLEMS WITH THE FINAL VERSION .................................................................................... 20
    6.3         ALTERNATIVE SOLUTIONS ..................................................................................................... 20
    6.4         FUTURE WORK ....................................................................................................................... 21
7      APPENDIX ................................................................................................................................... 21

8      GLOSSARY OF TERMS ............................................................................................................ 25

ACKNOWLEDGEMENTS ................................................................................................................. 26

SOURCES ............................................................................................................................................. 26




                                                                                                                                                 2(26)
  Daniel Offrell                                                          20P Examensrapport
  Magister Automatisering 160P


     1 Introduction
   The AASS Mobile Robotics Lab of Örebro University is working on the development
of a network of Physically Embedded Intelligent Systems (PEIS). The vision is to create
an environment that provides services in your daily life through the use of independent
robots and electronic systems in various parts of your home that communicate with each
other. Instead of inventing a super-robot that can act as a servant, these independently
simple devices will cooperate to perform potentially complex tasks. This is called a
PEIS-Ecology.

     1.1 Project objectives
  This ex-job project will deal with the AIBO robot-dogs from Sony. At AASS they
have built a prototype PEIS with some interconnected devices, for example two robots,
cameras in the ceiling and a fridge with an embedded computer device, and they would
now like to incorporate the AIBO's into it.

   The AIBO's will need to be interfaced with the existing infrastructure of the PEIS and
a set of programs needs to be written to make them exhibit some useful functionalities.
After that they need to be tested in a few experiments, the nature of which will be decided
during the project. Examples of experiments are: (1) the dog is requested by another robot
to go somewhere, take pictures, and send them back; (2) the dog moves around the home
and it takes information from the ceiling cameras to know its own position. In (1), the
second robot might possibly be replaced by a human using a palm computer to talk to the
AIBO.

  Thus the original objectives of this exjob project were:

      1. Design and implement a software interface between the AIBO and the PEIS
         Ecology framework, in compliance with the "PEIS Middleware" standard used
         in that framework.

      2. Design and implement a small library of programs that allows the AIBO to
         perform a basic set of sensing and control functionalities. These may include:
         acquire an image, moving to a given location, changing posture, acquiring and
         producing sounds, etc. (The actual set of functionalities will be decided during
         the execution of the project.)

      3. Run a set of experiments in which the AIBO is incorporated in a PEIS-Ecology
         together with other robots and/or a human user, to perform some simple tasks.
          (The details of the experiments will be decided during the execution of the
         project.)



  As it will be explained, these original objectives turned out to be very ambitious, given



                                                                                     3(26)
   Daniel Offrell                                                          20P Examensrapport
   Magister Automatisering 160P
the complexity of both the AIBO and the PEIS middleware. As a consequence, the
objectives had to be scaled down during the execution of this project. In particular most
effort was put on the first objective, while providing simplified solutions for objectives 2
and 3. It should be stated that objective 1 is the most important and critical one.

     1.2 Methodology
      -   Learn to use tools for programming the AIBO

      -   Survey what functionalities AIBO has and decide which to implement.

      -   Learn about the PEIS Middleware standard and tools.

      -   Implement the AIBO interface to the PEIS Ecology.

      -   Experiment using the AIBO incorporated in a full PEIS Ecology. Revise the
          interface and functionalities.

      -   Evaluate the results.

     1.3 Outline of this document
   This report begins by introducing you to AIBO and the PEIS-Ecology in Chapter 2.
Chapter 3 gives an overview of how the OPEN-R objects in the prototype interact.
Chapter 4 describes what the OPEN-R objects in the prototype do. Chapter 5 describes
the work on learning about OPEN-R, the making of objects to provide communication
and some functionality and converting the PEIS-kernel to run in OPEN-R. Finally
Chapter 6 discusses the result.

     2 Background
   This chapter introduces you to the main elements of AIBO, OPEN-R and the PEIS-
ecology, providing the background needed to understand this report.

     2.1 About AIBO
   AIBO is a toy-robot in the shape of a little dog developed and sold by Sony (its
production has now been discontinued). It is an autonomous robot that can walk around
by itself, detecting and interacting with its environment. In its commercial use it is
programmed to act like a real dog. It interacts with and learns from its owner and
develops through different alternative personalities depending on the interaction with its
owner.

  Sony has also released programming tools for AIBO: r-code, which is intended for
hobbyists, and OPEN-R, for more advanced low level control.

   In the research area of robotics many have found AIBO to be a suitable platform for


                                                                                      4(26)
   Daniel Offrell                                                                20P Examensrapport
   Magister Automatisering 160P
AI-research at a reasonable price and there is a “Sony Four-Legged Robot League” in
Robocup (football tournament for robots) where AIBO dogs are used.

  Sony made several series of AIBO before discontinuing it. Each new version added
some new features in its design and software.

     2.2 Hardware
   For this project I had an AIBO
of model ERS210 equipped with a
LAN wire-less network card.

    Its head has three degrees of
freedom: one joint for tilting back
and forward at the base of the neck
and two joints for panning and
tilting from side to side
respectively at the connection of
neck and head. The head is
equipped with a camera, two
microphones, a speaker and a
range sensor. Its ears can flip back
and forward between two positions
and its jaw can be opened and
closed indiscreetly.
                                                          AIBO of model ERS210
   The legs have three degrees of
freedom each: one knee joint and
two joints at the legs connection to the body for swinging the legs in parallel to the
body’s vertical plane or perpendicularly to it. The soles under its feet act as touch sensors
so that it can detect if it is standing on the ground or being lifted.

   The tail has two degrees of freedom, being able to waggle left, right, up and down.

    Input devices are the microphones on the head, the touch sensors under its feet and
four touch sensors (buttons) on its back, torso, cheek and the top of its head. Output
devices are the speaker, seven LEDs in its face, one LED on its chest and one LED on the
tail. If you like you can count the ears, jaw and tail as output devices as well, as they have
no other practical function.

     2.3 OPEN-R
   The operating system for AIBO is a real time OS named Aperios that can run several
processes simultaneously.

   OPEN-R is the interface promoted by Sony for developing software for AIBO. Sony
released it for non-commercial use only. It is modular and uses “OPEN-R objects”


                                                                                          5(26)
   Daniel Offrell                                                           20P Examensrapport
   Magister Automatisering 160P
(hereafter referred to merely as objects) which are not to be confused with C++ objects,
although OPEN-R is programmed using C++. Each object runs a process. There is no
main() in an object to start the process; instead it has a number of entry points. Firstly the
methods doInit() and doStart() is run (in consecutive order) after booting of the AIBO,
while doStop() and doDestroy() is run at shutdown. Secondly there can be methods that
are run when a message is received from another object. Special entry points also exist.
Each Aperios object is defined in a “core class” that is actually an ordinary C++ class,
which inherits from the base class OObject.

   There are also a number of embedded objects in the OPEN-R system that provides
services; among others those that deal with moving the joints and delivering image
information from the camera. You get information from and send commands to joints,
camera and microphone etc. through message passing with these objects. Messaging to
and from these is done in the same way as between objects created by the user.

     2.3.1 Object Messaging
   To send messages between objects you have to set up the connection between them in
an external description file, where it is defined which objects are communicating with
each other and what kind of data they send. Outgoing connections from an object are
called subjects while the connections receiving messages are called observers. Each
connection works only in one direction and is an entry point for the receiving object,
which needs a method that is run when a message is received where the data can be
retrieved: the observer. You can set up several connections between two objects for
different types of messages. When the subject wants to send a message it sends a
‘NotifyEvent’ to the observer. The observer answers with a ‘ReadyEvent’ that tells the
subject if the observer is ready to receive or not. If the observer is ready the subject
proceeds to send the message data. The objects are single threaded and can therefore only
process one message at the time. Any additional messages sent to an object that is
currently processing a message will therefore have to be put in queue.




   You can even set up connections like these between objects running on different
processors (in different dogs or on a computer running an emulation of Aperios) through
a ‘TCPGateway’ object. In this case you actually define a connection from subject to the
TCP/IP layer, and in the receiving system from the TCPGateway object to the observer.


                                                                                        6(26)
   Daniel Offrell                                                          20P Examensrapport
   Magister Automatisering 160P
All objects on both hosts are executed as if part of one program. It is possible to run the
whole program controlling an AIBO from a PC (a remote host) in this way, where only
the connections between the embedded objects in Aperios and the TCP layer need be
defined in the AIBO. This is called remote processing.

    Since the PEIS-kernel (the PEIS-kernel implements the PEIS-ecology, see chap. 2.4.2)
is developed and run on a Linux platform, there was a possibility (and might be easier) to
use remote processing for incorporating an AIBO as a PEIS-component. The PEIS-kernel
would then run on a Linux PC while the rest of the program could lie in the AIBO itself.
The disadvantage of this solution is that you would always need a PC present and running
as interface between the AIBO and the PEIS-ecology. A much more satisfactory solution
would be if the PEIS-kernel could be run directly on the AIBO and make us of TCP or
UDP protocol to connect to the PEIS-Ecology without the need of an extra computer,
which is what I have tried to do.

     2.4 PEIS-Ecology
  The AASS Mobile Robotics Lab of Örebro University is working on a network of
Physically Embedded Intelligent Systems (PEIS); a system with many different units
connected and communicating with each other in order to cooperate and perform tasks.
This is called a PEIS-Ecology.

     2.4.1 Vision
   The vision is to create an environment that provides services in your daily life through
the use of independent robots and electronic devices. The power of the PEIS system does
not lie in advanced intelligent devices. Instead of inventing a super-robot that can act as a
servant in all kinds of situations, the independently simple devices in the PEIS-Ecology
will communicate and request functionalities from each other in order to cooperate and
perform potentially complex tasks. Examples of these devices could be robots able to
carry stuff around, autonomous cleaners, a monitoring system of cameras, intelligent
kitchen appliances and packages for groceries and other things with microchips
containing information about its contents. The AASS believes that in a few decades this
technology can be commonplace in our homes and improve the quality of your daily life,
especially for the disabled and senior citizens.




                                                                                       7(26)
   Daniel Offrell                                                                            20P Examensrapport
   Magister Automatisering 160P




                     Example of a simple ecology with three PEIS components: An autonomous
                     vacuum robot, a camera tracking system and a package equipped with a
                     PEIS chip (e.g. IC-tag).

   To make this vision real, input is needed from the fields of robotics, artificial
intelligence and ubiquitous computing. First, robotics is needed in various devices to
build the base of the ecology. These would not necessarily be only mobile robots or any
kind of robot as we recognize them today. Secondly, some intelligent system is needed to
coordinate the tasks, recover from failures and deal with missing information, and so on.
For this Artificial Intelligence technology will be used. Thirdly, all the individual parts in
the environment need to be connected together in a network to allow communication and
cooperation. The field of ubiquitous computing is important in the task of connecting
multiple heterogeneous computer systems.




     2.4.2 Architecture
   A reference architecture is needed when implementing the PEIS-Ecology to enable the
communication between its components. The PEIS-Ecology reference architecture
combines event based and tuple based communication models within a component
framework. The architecture is implemented in the “PEIS-kernel”. All communication
between components takes place as an exchange of tuples (units that can be filled with
different kinds of data) through the PEIS-kernel middleware. This is a software layer on
top of the operating system and provides platform independent communication primitives
for reading and writing from the tuple-space, stores local portions of the tuple-space, and
manages events. Each CPU that runs a PEIS component must have a PEIS-kernel.



                                                                                                      8(26)
  Daniel Offrell                                                                                     20P Examensrapport
  Magister Automatisering 160P
   When a PEIS component joins the ecology it publishes an XML (Extensible Markup
Language) description of its components, which is treated as a tuple, to the tuple space
where info is stored for the benefit of all components in the ecology about what tuples
exist and what data they contain.

   The PEIS-kernel is developed iteratively with several versions having been
implemented, each with more of the desired design implemented. The current PEIS
version is generation 3. When developing a demonstration platform it was decided that
the first version of the PEIS-kernel would be developed and run on Linux systems,
primarily since all robots and other robot technologies at the AASS uses Linux platforms.
Also Linux can be run on many different types of hardware. C was chosen as
programming language since this allows programs from several other languages; for
example C++, Lisp and Java; to interface with the PEIS-kernel and be used as PEIS
components. There also exists ambition in the future to implement a platform
independent version of the PEIS-kernel using java space.




            Through routing, all components in both clusters are seamlessly connected into one big P2P-network.



   The most important task of the PEIS-kernel is to create an ad-hoc peer-to-peer (P2P)
network between all PEIS components in the ecology. Even if two components aren’t
directly linked to each other the PEIS-kernels of interlaying objects relay the messages
through the P2P network, providing a transparent communication bridge between all
components. When a new component connects to any one in the ecology, the kernel
detects this and makes all included components aware of it through the P2P network. This
communication mechanism is used to set up the tuple space where the components can
issue write and read commands.

  The PEIS-kernel is built in four layers




                                                                                                                  9(26)
  Daniel Offrell                                                          20P Examensrapport
  Magister Automatisering 160P




   The top-level layer is the PeisKernel API, with an extra layer for enabling multi
threaded PeisKernel API.

  Next is the Tuple Space Layer where info about all tuples is handled.

   The Service Layer takes care of network initialisation, creating, sending and
translating network pages, discovering nodes in the network, broadcasting host info,
routing messages, registering/cancelling services, connection management, neighbours
management, topology management, trace service (genetic).

   Last is the Communications Layer that takes care of the low level communication
(TCP, UDP, Ethernet, etc…). The Communications Layer provides two types of
transmissions: one-to-all (broadcast) or one-to-one (to a given address or as reply to a
message). The broadcast mode has not been implemented in this project since the needed
low-level functionalities are not available in OPEN-R (see chap. 4.1.1).

     2.4.3 Test bed
   The AASS has built an experimental test-bed where a PEIS-Ecology can be
implemented to verify and explore its possibilities. The test bed consists of a room built
up to resemble a real Swedish mini apartment; a kitchen, a living room and a bedroom;
with a number of PEIS-components; including perception-, reasoning- and action
components; and an observation deck to observe the room and its components from.




                                                                                   10(26)
   Daniel Offrell                                                                               20P Examensrapport
   Magister Automatisering 160P




       3 Overview of the prototype




   The schematic shows how the objects in the prototype interact with each other; what
events in each objects that leads to a message transferring data to another and what the
receiving object does in response. Note that the transfers between objects are independent
of each other and don’t need to happen in any given order.

   ImageObserver handles image data from AIBO’s camera and sends it to P2P in
regular intervals in order for P2P to start a new program step and update the image tuple.
P2P is the modified PEIS middleware that handles the networking. UDPComm handles
the incoming and outgoing wireless UDP communication.

   These objects will be described in detail later in this report.

   PeisKernel layers
PeisKernel API                 Get/set tuple, subscribe/unsubscribe. Register/cancel callback
 Multithreaded PeisKernel APII
Service layer                  Store/retrieve/propagate tuples. Subscriptions,
                               callback hooks...
Tuple-space layer              Create/send/receive/route packages.
                               Topology management, time sync...
Communication layer             TCP, UDP, serial links. Serial...




                                                                                                        11(26)
   Daniel Offrell                                                          20P Examensrapport
   Magister Automatisering 160P
   The changes done to the PEIS-kernel are in the communication layer. Multithreaded
PeisKernel is not implemented at all in the prototype.

     4 Objects in the prototype
     4.1 P2P
   This is the object that runs the PEIS-kernel. It uses a reworked version of the file p2p.c
as a core class.

     4.1.1 Porting of the PEIS-kernel
   Since OPEN-R is built up on the principles of having parallel processes in different
objects I decided that the obvious and best way to make the PEIS-kernel work in AIBO
would be to make an OPEN-R object out of it. Since the main part of the kernel is taken
care of in the class p2p.c I decided to use the file p2p.h as the definition for P2P’s core
class.

   For this project the use of TCP and broadcasting is disabled in the PEIS-kernel. The
broadcasting has been disabled since I have found no instructions or help about how it
works in OPEN-R. There is evidence that it might be possible to use broadcast in OPEN-
R, as it is mentioned in the document “OPEN-R SDK OPEN-R Internet Protocol
Version4” that a sent IP packet might be a broadcast packet, but nowhere in the
documentation or on internet have I found any instructions or help about how to
implement broadcasting in OPEN-R. TCP hasn’t been implemented because of lack of
time to learn how to make it work in OPEN-R.

   Changes made in P2P.cc (formerly p2p.c) are mainly all code dealing with sockets
(opening sockets, sending & receiving messages).

     4.1.2 Interface
   Methods added in P2P are for receiving new messages from UDPComm for the socket
buffers, popping message (and sender data) from the buffers, opening a new socket,
sending messages and initialising a new program step for the PEIS kernel.
ImageObserver sends messages to P2P, containing image data and time since booting,
with 0.4-second intervals that is caught in the method Step(), which in its turn calls
peisk_step().

          void Step(const ONotifyEvent& event)
          This method is run when the message from ImageObserver is received. It
          updates the global variable time_in_seconds with the time since booting
          contained in the message. It updates a tuple with the image data and it calls the
          method peisk_step() to start a new program step in the PEIS-kernel. The first
          time this method is run (right after booting) it also makes a call to
          peisk_connect() to initialize connection to the PEIS-ecology.


                                                                                      12(26)
  Daniel Offrell                                                           20P Examensrapport
  Magister Automatisering 160P
          void messageReceived(const ONotifyEvent& event)
          This method is run when a message is received from UDPComm containing a
          received UDP packet. The received message data is stored in a socket buffer
          together with data about the sender (see chap. 4.1.3).

          int openSocket(int port)
          This method is called by the kernel when it wants to open a socket for
          communication. It sends a message to the object UDPComm, which creates an
          endpoint and binds it to the chosen port if free.

          int sendTo(int sockindex, struct udpaddr send_data)
          This method is called by the kernel when it wants to send a message. It sends a
          message with the message data and destination info to UDPComm, which
          sends the message data as an UDP packet.

          struct udpaddr recvMessage(int sockindex)
          This method is called by the kernel when it wants to receive incoming
          messages. It checks the socket buffer of the appropriate index and if it is not
          empty it returns the oldest message in the buffer.

     4.1.3 RecBuff - my sockets
   Since OPEN-R doesn’t make use of sockets, but handles UDP and TCP through
messages to the IP stack (see chap. 4.2.1), I needed to replace all code that dealt with
creating, listening to or sending from sockets with my own socket function.

   I decided it would be best if UDPComm listens for messages on all connections, set up
on command from P2P, and relays them, together with IP and port number, to P2P where
they are saved in a buffer until the PEIS-kernel wants to receive a message from
respective connections. The alternative would have been to store the incoming messages
in UDPComm, and send a message from P2P requesting them for the PEIS-kernel. This
would work just as well, but it would result in more inter object messages, as the PEIS-
kernel checks for new messages much more often than new messages are actually
received.

   To store the incoming messages, I made the class RecBuff to use as buffer. In RecBuff
the messages are stored together with the IP address and port of the sender in a struct
udpaddr. Methods with list handling for inserting and extracting posts are implemented
in RecBuff. A global array for the PEIS-kernel,
RecBuff socketbuffers[PEISK_MAX_CONNECTIONS]; is defined in P2P.h so that
each “socket” has its own buffer. The incoming messages are stored as FIFO lists.

    The limit is set to one hundred messages per buffer. This however is not based on any
actual evaluation of general memory requirements for the messages or available memory
in the AIBO and may be better chosen in later development.




                                                                                     13(26)
  Daniel Offrell                                                        20P Examensrapport
  Magister Automatisering 160P

     4.2 UDPComm
   UDPComm is the object that provides wireless IP communication with the PEIS-
ecology.

   UDPComm creates endpoints (explained further down) for UDP communications.
When the PEIS-kernel in the P2P object opens a new socket it sends an index number and
destination port to UDPComm which creates a new endpoint, binds it to a port and starts
receiving on that port. When it receives an incoming UDP packet it transfers it to P2P
together with the sender’s port and IP-address. When the PEIS-kernel has an outgoing
message it sends it to UDPComm together with the destination port and UDPComm
sends the message as an UDP packet.

     4.2.1 Wireless communication in OPEN-R
   OPEN-R has an IP protocol stack using IP version 4 (IPv4), which includes several
protocols that supplements the basic IP protocol.

  The included protocols are:

      •   IP (Internet Protocol) – The base protocol for communication over the Internet,
          providing connectionless and unreliable delivering of packet-oriented
          datagrams.

      •   TCP (Transmission Control Protocol) – Runs on top of the IP protocol,
          providing objects with a connection-oriented, reliable, byte stream service.

      •   UDP (User Datagram Protocol) – Runs on top of the IP protocol, providing
          objects with an unreliable datagram delivery service.

      •   DNS (Domain Name System) – A service for mapping domain names to IP
          addresses and vice-versa.

      •   DHCP (Dynamic Host Configuration Protocol) – A service for allocating
          reusable network addresses and additional configuration options.

   In the current PEIS version they use mostly TCP but UDP will suffice. Since I had
some trouble getting TCP to work in OPEN-R and I didn’t want to spend too much time
with this part of the project I have disabled TCP in the prototype’s PEIS-kernel and only
use UDP.

   ANT, the OPEN-R Networking Toolkit, runs the IPv4 protocol stack. IPv4 and ANT
are both included in IPStack, which is an OPEN-R system layer. Endpoints are ANT
objects on top of the protocol stack and are responsible for communication between
objects and the stack. Creating endpoints and giving commands for sending and receiving
packets is done through special messaging. The messages sent to the IPv4 stack is
inherited from the structure ‘antEnvMsg’, which provides basic message handling



                                                                                  14(26)
  Daniel Offrell                                                                                 20P Examensrapport
  Magister Automatisering 160P
constructs. Each service provided by the protocol is requested with a special inherited
message type. An object needs one endpoint for each network connection. It can send
packets while it’s waiting to receive through the same endpoint.




                       Objects send requests for network services to endpoints in the IPStack.



   Since the protocol stack doesn’t share the same address space as objects they cannot
exchange ordinary pointers. Therefore a shared memory buffer has to be set up for the
endpoints. This buffer is used for transmitting connection configurations as well as the
data to be sent or which has been received.




                Shared memory buffers map memory areas to the address spaces of objects and the
                          protocol stack, enabling them to exchange pointers to data.




                                                                                                         15(26)
  Daniel Offrell                                                          20P Examensrapport
  Magister Automatisering 160P

     4.3 ImageObserver
   The ImageObserver object provides pictures from the AIBO’s nose camera and at the
same time is used to tell P2P when to initiate a new program step for the PEIS kernel.
The ImageObserver object was part of one of the sample programs downloaded from
Sony. It took images from the AIBO’s camera and saved them to the memory stick. So
what had to be done was to change this object so that instead of saving the image as a file
on the memory stick it would send it to another object in a format that could be sent in a
UDP packet.

   Image data is sent 25 times per second from the internal object OvirtualRobotComm
through an inter object message that transmit a data type OfbkImageVectorData. This is
part of the Aperios operative system and cannot be altered by the user as far as I know.
Any object created by the user can receive the image. ImageObserver is set up to receive
these messages.

   In regular intervals when ImageObserver receives OfbkImageVectorData it sends a
message to P2P with the image data converted into ppm format along with the current
time since booting (which is calculated based on how many times the
OfbkImageVectorData has been received). When P2P receives this message it will update
the picture tuple, update the time since booting and start a new PEIS step.

   Note; this method for keeping track of the time since booting had to be used since no
time function that does this could be found for OPEN-R.

     5 Issues with porting of the PEIS-Kernel
   All necessary library files, instructions for programming of AIBO and some sample
programs could be downloaded from Sony’s resource page dedicated to AIBO.
http://openr.aibo.com/

   I briefly tried using Tekkotsu, a tool aid for programming AIBO developed by
Carnegie Mellon University in Pittsburgh Pennsylvania USA. I downloaded the software
(http://www.cs.cmu.edu/~tekkotsu/index.html) for Tekkotsu and tried installing it but
couldn’t get this to work, probably because the computer I was working on didn’t have a
Java virtual machine installed.

     5.1 IP communication
   Among the sample programs for AIBO downloaded from Sony\s support site were
echo servers and echo clients for TCP and UDP respectively. At first these wouldn’t
work. This turned out to be because of the firewall in the PC that stopped all incoming
packets. After having turned of the firewall, UDP communication worked fine. TCP still
wouldn’t quite work however. It did work when I ran a TCP echo server on the AIBO but
not when I ran an TCP echo client. Although this problem could surely be solved with
time, I felt that I had spent too much time on this part already. Since UDP was working
and would be sufficient for connecting to the PEIS-Ecology I decided to move on to the


                                                                                    16(26)
   Daniel Offrell                                                           20P Examensrapport
   Magister Automatisering 160P
next step, planning to add TCP if I still had time by the end of the project.

     5.2 Testing
   The prototype was tested by letting it try to connect to a PEIS-component (tupleview)
on a Linux computer. Since broadcast isn’t implemented it must be hard coded to try and
connect to a certain IP address, which means that it is dependent on a PEIS component
already being run on this IP address.

   I needed to make several changes to my original prototype during debugging because
of things I had misunderstood about the PEIS-kernel. Debugging in OPEN-R is a tedious
business, since there are no debug tools. There was only a log function (Emonlog) that
would tell you in which object a crash had occurred and on which line in which file. If the
crash had occurred in a standard function, like memcpy for example, it would only tell
you on which line in the library file memcpy.c the crash had occurred and you had to
check all the memcpy functions in the PEIS-kernel file to find in where the problem was.

   Here is an example of Emonlog being used:

[duckwing@fors34 NetworkComm]$ mount /mnt/ms/
[duckwing@fors34 NetworkComm]$ cp /mnt/ms/open-r/emon.log .
[duckwing@fors34 NetworkComm]$ emonLogParser emon.log
context:      8020f580
object:      p2p
[duckwing@fors34 NetworkComm]$ mv emon.log P2P/
[duckwing@fors34 NetworkComm]$ cd P2P/
[duckwing@fors34 P2P]$ emonLogParser emon.log p2p.nosnap.elf
context:      8020f580
object:      p2p
badvaddr:      fdeffffe
epc:        8084c044
ra:        8084c010
target address: 8084c044 (epc)
gp:        808d6cb0
_gp:        0048f0d0
static addr: 00404464
symbol:       0040439c T P2P::peisk_step()
[duckwing@fors34 P2P]$ mipsel-linux-addr2line -e p2p.nosnap.elf
00404464
/home/duckwing/NetworkComm/P2P/P2P.cc:1615

   Eventually AIBO managed to connect with tupleview as a new PEIS-component,
although the connection is not entirely stable. It will usually be disconnected from
tupleview after a while (sometimes to reappear) and the component id does not show up
properly. The tuples show up in tupleview as being available from the AIBO component,
but when asking AIBO to send the image itself it crashes. According to the log function
this crash occurs in the OPEN-R IP stack. A possible explanation for these problems is


                                                                                    17(26)
  Daniel Offrell                                                        20P Examensrapport
  Magister Automatisering 160P
data corruption because of the unreliability of UDP and wireless communication.
Alternatively the data is corrupted somewhere in the PEIS-kernel.

   The UDP communication seamed to be working fine when receiving incoming
packages. There is an error message in UDPComm about the UDP connection being busy
once in a while, but when this occurs it seams to simply run the receive function again
until it works. All received packets from tupleview appear to be received intact.

   Another issue was that of calculating the current time. In order to work correctly the
kernel should run one program step with no more than 0.1 second intervals (this meant
intervals of 0.08 seconds in AIBO), but when ImageObserver sent messages to P2P at
that rate (with image data and current time) the CPU couldn’t handle them fast enough
and the time in P2P lagged behind real time. This problem was solved by only including
the image data to P2P for every tenth step (about once a second).




  This is Tupleview before I’ve turned on the AIBO. You can see that the only PEIS
component present is Tupleview itself.




                                                                                  18(26)
  Daniel Offrell                                                        20P Examensrapport
  Magister Automatisering 160P




  Here AIBO’s PEIS-kernel has connected to Tupleview; named “(0)” in the display.
You can see that it has a tuple named “image” uploaded.

  Description of the current problems:

      •   An error turns up once in a while in UDPComm::ReceiveCont(): receiveMsg->
          error = 3. This means that the UDP connection is busy. This is no real problem
          though since each time this occurs ReceiveCont() is automatically called again
          so that you don’t miss the incoming packet.

      •   When AIBO’s PEIS-kernel connects to tupleview and you see the new
          component in tupleview’s display the name (which is set to “AIBO”) is not
          correctly transmitted. It turns up as “0”. Further more it sometimes looses
          connection with tupleview after a minute or so for unknown reasons. Emonlog
          shows that the crash occurs on line 1615 in P2P.cc in these cases. The code on
          that line is shown below.

       if(peisk_printLevel & PEISK_PRINT_STATUS)
         {
           PEISK_ASSERT(timeElapsed < 0.1, ("peisk_step() called to slow. ts
      elapsed=%3.3f\n",
                             timeElapsed));
         }

      •   When you try to access the image tuple from AIBO in Tupleview a crash
          occurs in AIBO. When using Emonlog it says that the crash occurred in the IP-


                                                                                  19(26)
  Daniel Offrell                                                         20P Examensrapport
  Magister Automatisering 160P
          stack.

      [duckwing@fors34 NetworkComm]$ emonLogParser emon.log
      context:   8020e840
      object:   IPStack


     6 Discussion and Conclusion
     6.1 Achieved
    The PEIS-Kernel has been ported by making it into an OPEN-R object. To do this the
main changes that had to be done was to replace the code for IP communication, since
this is handled differently in OPEN-R than in C. The use of TCP and broadcasting is not
implemented. All the low-level communication is implemented and functioning. The
testing has shown that it is possible to run the PEIS-kernel on an AIBO’s CPU and that it
is able to connect to the PEIS-ecology.

   There has not been constructed a whole library of tasks for the AIBO to perform but
the prototype is set up to provide a tuple with images from AIBO’s camera for the
network. There is a problem when trying to send the image itself though, as a crash
occurs in the OPEN-R IP stack. This might be due to corrupted data.

     6.2 Problems with the final version
   Because I have made changes in the PEIS-kernel code when porting it to OPEN-R it is
no longer the same version that is used in the other PEIS-components, which could
possibly cause compatibility problems when the official PEIS-kernel is developed further.
This would mean additional work is needed to also update the OPEN-R version of the
kernel.

   Since broadcasting isn’t implemented, an IP address has to be hard-coded in the kernel
for the AIBO to connect to at start up, which means that it can’t connect if no component
with that IP is already connected.

   Another problem is the program doesn’t use a proper time function that keeps track of
the real time. Instead the time is calculated based on how many times new picture data
has been sent from the internal object OvirtualRobotComm. This method is sufficient for
the kernel to function correctly, but since the CPU can’t keep up if you send to much data
at each time, causing the calculated time to lag behind real time.

     6.3 Alternative solutions
   The use of remote processing (see chap. 2.3.1) could be used to implement the PEIS-
kernel for OPEN-R. I do not know if the advantages of this solution would be enough to
compensate for the need to run a PC linked to the AIBO all the time when you want it
connected to the PEIS-ecology.


                                                                                   20(26)
   Daniel Offrell                                                              20P Examensrapport
   Magister Automatisering 160P
   Also maybe another possible solution for the porting itself: the PEIS-kernel might
have been kept as it was, without changes, and instead one would make an OPEN-R
object that acts as an interface, which takes care of all functions that aren’t present or is
different in the AIBO (mainly those dealing with sockets). This would make it easier to
update the version of the PEIS-kernel in AIBO when PEIS is developed further.

      6.4 Future work
   The implementation of broadcasting would be desirable so that you won’t have to
hard-code the IP address of an already connected PEIS-component for the AIBO to
connect to at start up. It could be investigated if this is at all possible to implement. If this
is not found to be (easily) possible, a goal could be to find some alternative solution to
the problem.

   Future work could be to come up with and implement tasks that an AIBO can fulfil in
the PEIS ecology. Suggestions: Provide an extra, mobile camera for the monitoring
system. Move small objects around. Act as guard dog.

      7 Appendix
   Here the methods structs and class I have written in order to enable the PEIS-kernel
being run in OPEN-R is described.
   To understand what’s happening in the objects in more detail you should use the
documents OPEN-R SDK Programmer’s Guide, OPEN-R Internet Protocol
Version4 and OPEN-R SDK Level2 Reference Guide. I also recommend looking at and
experimenting with the sample programs from Sony’s resource page
http://openr.aibo.com/

      7.1 PEIS-kernel
  Here follows a description the methods I’ve written for P2P. These are the methods I
have used to replace all code dealing with sockets in the PEIS-kernel. They are declared
and defined in P2P.h and P2P.cc.
      • void Step(const ONotifyEvent& event);
          This method is an observer that observer receives messages from
          ImageObserver. “event” contains a string from which the current time is
          retrieved. Then it checks to see if image data is included and if so updates the
          image-tuple. Finally it starts another program step for the PEIS-kernel.
      • int openSocket(int port);
          This method opens a socket (in the class RecBuff) on the port given if it is free.
          This means creating an instance of RecBuff and sending a message to
          UDPComm with index and port nr. If ‘port’ is negative it will find a free port
          to open a socket to. Returns the port nr of the opened socket.
      • void messageReceived(const ONotifyEvent& event);
          This method is an observer that receives messages from UDPComm with
          received UDP-packets and information of its source. It retrieves from “event”
          which socket buffer the message should be stored in and the port and IP-


                                                                                         21(26)
Daniel Offrell                                                         20P Examensrapport
Magister Automatisering 160P
       address of the sender. Then it stores the message in the correct socket buffer.
   •   struct udpaddr *recvMessage(int sockindex);
       Pops the socket buffer with index ‘sockindex’ and returns the popped message
       if any.
   •   int sendTo(int index, struct udpaddr data);
       this method puts together a string with index of the socket sending the
       message, destination port and IP-address, size of the message being sent and
       the message string itself. Then it sends this string to UDPComm.
   •   Closing sockets
       Sockets are closed in the method peisk_closeConnection(), which I did not
       write but, as with all code dealing with sockets and UDP communication, I
       needed to modify it. This includes a call to RecBuff::closeSocket() and
       sending a message to UDPComm with the index of the socket being closed.

  7.1.1 RecBuff
RecBuff is the class I’ve written to use as sockets. Each instance of RecBuff is one
socket. It stores incoming messages in buffers, using a FIFO list, until the PEIS-kernel
requests them.
The messages are stored in struct udpaddr, which apart from the message itself
contains the senders IP-address as four bytes and integers for the length of the message
and the sender’s port.
Both RecBuff and udpaddr are declared and defined in RecBuff.h and RecBuff.cc.
   • RecBuff();
        Constructor.
   • RecBuff(struct udpaddr data);
        Constructor. Puts “data” first in the buffer.
   • ~RecBuff();
        Destructor.
   • bool openSocket();
        Sets the boolean “open” to true.
   • bool closeSocket();
        Empties the buffer and sets “open” to false.
   • bool isOpen();
        Returns the state of “open”.
   • int receivePort();
        Returns the port for the socket.
   • void setPort(int port);
        Sets the port for the socket to ‘port’.
   • bool appendBuffer(struct udpaddr data);
        Adds “data” at the end of the buffer.
   • struct udpaddr *popBuffer();
        Returns the oldest udpaddr in the buffer and removes it from the buffer.

  7.2 UDPComm
Here I will explain the most important things happening in UDPComm. This OPEN-R


                                                                                 22(26)
Daniel Offrell                                                        20P Examensrapport
Magister Automatisering 160P
object was made mostly by modifying the sample program UDPEchoClient.
   • OStatus BindNew(ONotifyEvent& event);
       This is the observer that receives the message from P2P:: openSocket() when
       the PEIS-kernel wants to open a new socket. Here the index of the socket and
       port nr to start receiving on is retrieved from “event”. An endpoint is bound to
       the port and Receive() is called to start listening on the port.
   • OStatus InitSendMessage(ONotifyEvent& event);
       This is the observer that receives the message from P2P::sendTo() when the
       PEIS-kernel wants to send a UDP message. Destination port and size of
       message (integers), destination IP-address (four bytes) and the message string
       itself is retrieved from “event”. The proper endpoint is set up to send the
       message by putting the destination data and the message in a shared memory
       buffer to be sent to the IP-stack. Then Send() is called.
   • OStatus Send(int index);
       In this method the command to send a UDP packet is sent to the IP-stack
       through the endpoint.
   • void SendCont(ANTENVMSG msg);
       This method is an entry point to the object that is called when the IP-stack is
       done sending the UDP packet. Here you find out if it was successful.
   • OStatus Receive(int index);
       In this method the command to start listening on a port for an incoming UDP
       packet is sent to the IP-stack through the endpoint.
   • void ReceiveCont(ANTENVMSG msg);
       This method is an entry point to the object that is called when a UDP-packet is
       received. A string is constructed with index of the receiving endpoint and port
       of the sender (as integers), IP-address of the sender (four bytes) and the
       message itself and the sent to P2P.
   • void RemoteClose(ONotifyEvent& event);
       When the PEIS-kernel closes a socket P2P sends a message that is received in
       this observer. Here the endpoint with the index retrieved from “event” is closed
       down.
   • void CloseCont(ANTENVMSG msg);
       This is an entry point to the object that is called when the IP-stack has closed
       down an endpoint. It confirms if the endpoint of the appropriate index is indeed
       closed.

  7.3 ImageObserver
Here I will explain the most important things happening, regarding the PEIS-kernel, in
ImageObserver. This OPEN-R object was made mostly by modifying the sample
program of the same name.
   • void Notify(const ONotifyEvent& event);
       This observer receives OfbkImageVectorData from the internal object
       OvirtualRobotComm 25 times/second. Each time Notify() is called it increases
       the double “seconds” with 0.04 to keep track of the current time since start-up.
       Every second time (i.e. 12.5 times/second) Notify() is called it goes on to send
       a message to P2P for starting a new program step in the PEIS-kernel by calling


                                                                                23(26)
Daniel Offrell                                                        20P Examensrapport
Magister Automatisering 160P
       SendData();. Every tenth time it calls SendData it also includes the
       OfbkImageVectorData.
   •   void SendData();
       This method constructs a string with the current time in seconds (as a double)
       and sends it in a message to P2P.
   •   void SendData(OFbkImageVectorData* imageVec);
       This method converts the OfbkImageVectorData into ppm format and then
       constructs a string with the current time in seconds (as a double) and the image
       data and sends it in a message to P2P.




                                                                                24(26)
Daniel Offrell                                                       20P Examensrapport
Magister Automatisering 160P


  8 Glossary of terms
       AIBO : The robot dog developed and sold by Sony.
       C : A popular programming language.
       C++ : Another popular, object oriented, programming language originally
       based on C.
       Class : Classes are used to group related variables and functions in object
       oriented programming.
       CPU : Central Processing Unit. A computers processor.
       FIFO list : First-In-First-Out list. Useful if you need to queue for example
       incoming data.
       IP : Internet Protocol. Protocol for communication over the Internet with
       packet-oriented datagrams.
       Object : The basic building blocks in object oriented programming. Each
       object has its own purpose and can interact with other objects.
       OPEN-R : "OPEN-R is the interface that Sony is promoting for the
       entertainment robot systems to expand the capabilities of entertainment
       robots. This interface is layered and optimised to enable efficient development
       of hardware and software for robots”. OPEN-R SDK Programmer’s Guide.
       PEIS : Physically Embedded Intelligent Systems.
       Ppm file : Portable Pixel Map. A simple format for colour images.
       Remote Hosting : Running an OPEN-R program on another platform than the
       actual AIBO robot through wire-less communication.
       Socket : In computing this refers to a communication end-point.
       TCP : Transmission Control Protocol. Protocol for creating connections with
       reliable datagram transfers.
       Tupleview : A program that connects to the PEIS-Ecology as a PEIS
       component and lets you look at all available tuples in the network.
       UDP : User Datagram Protocol. Protocol for communication with unreliable
       datagram transfers.




                                                                               25(26)
  Daniel Offrell                                                       20P Examensrapport
  Magister Automatisering 160P


     Acknowledgements
  I would like to thank Alessandro Saffiotti, my supervisor for this project, Kevin
Leblanc who helped with OPEN-R and Mathias Broxvall who is the expert on the PEIS.

     Sources
  PEIS: Ecology of Physically Embedded Intelligent Systems. http://aass.oru.se/~peis

  A. Saffiotti and M. Broxvall. PEIS Ecologies: Ambient Intelligence meets
Autonomous Robotics. Proc. of the sOc-EUSAI conference on Smart Objects and
Ambient Intelligence. Grenoble, FR, October 2005.

   Ecologies of Physically Embedded Intelligent Systems, Final Report 2005
Prof. Alessandro Saffiotti, Dr. Mathias Broxvall, Mr. Marco Gritti, Mr. Beom-Su Seo

   OPEN-R SDK Programmer’s Guide
   OPEN-R SDK Level2 Reference Guide
   OPEN-R SDK Model Information for ERS-210
   OPEN-R SDK OPEN-R Internet Protocol Version4
http://openr.aibo.com/ Copyright Sony Corporation




                                                                                26(26)

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:6/23/2011
language:Swedish
pages:27