W/BO project - Wi-Fi over AIBO

Gilles RÉANT

Visiting student

Final Year project 2006

Supervisor: Meriel Huggard

4ICT9 Mobile Communications

Department of Computer Science

Faculty of Engineering and Systems Sciences

Trinity College, University of Dublin


I would like to thank my supervisor Meriel Huggard for having been so patient with me and for her continual guidance on this project.

I also would like to thank Jean-Christophe Baillie for having made a nightly build of URBI specially for this project needs.

I would like to thank Arkaitz Bitorika and Mathieu Robin for their presence during the project. Warm thanks to Mathieu for his unconditional help.

I would like to thank Shiu Lun Tsang from the Distributed Systems Group for lending me the Pocket PC I needed.

Thanks to Richard Pollock for trying to help me.

Very special thanks to François Pouliquen for having been such a friendly classmate, and such a good Mobile Communications partner.

I would eventually like to thank my girlfriend just for being herself.


W/BO project - Wi-Fi over AIBO

AIBO is one of several types of robotic pets designed and manufactured by Sony; there have been several different models since their introduction in 1999. Able to walk, "see" their environment via camera, and recognize spoken commands, these dogs are considered to be autonomous robots since they are able to learn and mature based on external stimuli from their owner or environment, or from other AIBOs.

The latest generation, called ERS-7, has a built-in wireless access card under the 802.11b norm (commonly called Wi-Fi), allowing the AIBO to be permanently connected to a network during the day, continuously sending and receiving data. The last generation of the firmware (Mind 3) allows the dog to create its own blog and update it every day, completely automatically, by filling it with pictures and text. This robot is used by families, children, techies and researchers alike because of its tremendous possibilities and in spite of its no less tremendous price.

The wireless function was only exploited as a network connection by Sony, but more surprisingly, it was not really used by other programmers, although many free-to-use Software Development Kits (SDKs) can be found on the net. This project is to consider the real possibilities of the pair Wi-Fi / AIBO. Therefore, as it is the tradition to name the AIBO when you first meet him, I named the one I was provided W/BO (pronounced wibo), for Wi-Fi over AIBO.

This project has several aims:

I hope that anyone will feel free to continue my work, as I was not able to provide a fully complete analysis on every possibility provided by the AIBO. My research raised new and interesting ideas to complete, and my algorithm can still be improved.

Table of contents

Acknoledgements 2

Abstract 3

List of figures. 6

List of tables 6

Aims of the project 7

Chapter 1: AIBO and other home devices 8

Connection with a PC 8

Connection with a Pocket PC 9

Cassiopeia E-200F 10

IPAQ h5450 11

Connection with a Playstation Portable (PSP) 12

Connection with a Mac 13

The ad-hoc connections 14

UPnP 17

Chapter 2: Security 20

Chapter 3: Sniffing algorithm 22

Project review 22

Description and evolution of the algorithm 23

Result and limitations of the algorithm 32

Conclusion 33

Tools used 34

Links 35

Appendix A: commentary on the program 36

Appendix B: the source code of the program: Gilles.u 40

Appendix C: my wireless configuration file: WLANCONF.TXT 48

List of figures

Figure 1.1: Representation of a connection between an AIBO

and a PC running on Windows/Linux 9

Figure 1.2: Representation of a connection between an AIBO

and a E-200F connected to a PC via a USB link 10

Figure 1.3: Representation of a connection between an AIBO

and a h5450 directly connected to the network 11

Figure 1.4: Representation of a connection between an AIBO and a PSP 12

Figure 1.5: Homebrew running on a PSP, receiving

the live video stream from a ERS-220 AIBO camera 13

Figure 1.6: Representation of an AIBO directly connected to a PC

(ad-hoc connection) 14

Figure 1.7: No ad-hoc connection was possible to realize 17

Figure 1.8: Summary of the realized connections 19

Figure 3.1: Description of the idea of the original algorithm 24

Figure 3.2: Description of the 5 different orientations 25

Figure 3.3: Example of four signal qualities recorded,

the fifth being a local minimum 27

Figure 3.4: Graph representing a typical signal quality variation

during three measurements 28

Figure 3.5: Graph representing a very scattered set of measurements 30

Figure 3.6: Graph representing a deconnection leading to an inaccurate average 31

List of Tables

Information on the different wireless informations implementation on AIBO 16

Aims of the project

This project was based on the original idea given by my tutor, Meriel Huggard, that we should use the AIBO in conjunction with Wi-Fi. Initially, we thought that making the AIBO a Wi-Fi sniffer would be interesting, as it seemed virtually possible. The AIBO would find all the possible networks, try to connect to one of them, and try to find the corresponding access point (the source of the waves) using a gradient of the signal quality.

After a while, I discovered that the only access point AIBO can connect to is defined by a file written on the memory stick, which means that every time you want AIBO to connect to another access point, you have to stop it and modify that file (writing the SSID and other network information so that the AIBO can connect to it). It is impossible for the AIBO to detect another Wi-Fi signal, extract the SSID from this signal and try to connect to the corresponding network on the go. So we had to give up the first part of the idea of sniffing; the AIBO is bound to be connected to a network previously defined. But trying to find the access point of a pre-determined wireless network and walk to it still seemed possible, so it became the main aim of this project.

I was also really curious to see what interaction this new generation of robot dog could provide. As this is a really expensive product, I was assuming that the added value was also consequent, and that the few devices I had would allow me to connect easily to the AIBO. People buying new products often take for granted that it will connect to their other devices. Unfortunately, most of the time this is far from being true. In the case the connection is even possible, devices usually require quite a lot of configuration. This is why having a list of possible interactions between devices is necessary.

Moreover, I was also interested by the security question, as it seems to become one of the most discussed problem of wireless networks. I thought I should also consider this point, to see if the AIBO was in accordance with the up-to-date encryption algorithms. Finally, I hope that my report will be a good starting point for anyone who wants to start programming on AIBO. Reading some parts of it may prevent some people from loosing a lot of time.

Chapter 1: AIBO and other home devices

One of the main interests of the latest generation of AIBO is the way it acts by itself, interacting with its environment, and evolving every day. This Artificial Intelligence feature is located in a program called AIBO Mind, coded by Sony. I was given a memory stick with Mind 2, and I worked a bit on it (Mind 3 is the last generation of Mind provided by Sony). Mind is located on a pink memory stick (the memory card format from Sony) commonly called the “Mind memory stick". It is important to note that you cannot write you own program and have it run on this memory stick. A separate “programming memory stick” is required for this purpose. If you load the programming memory stick on AIBO, it will only do the actions you asked it to. It is interesting to know that some developers on the web are currently trying to develop their own free and open version of Mind, although this project seems far too complicated for benevolent programmers.

There are not many ways to send data to AIBO. Either you have to open it, remove the programming memory stick and write on it with a memory card reader, or you can connect to the AIBO via Wi-Fi. It is evident that, when you are coding and debugging, the memory stick method quickly becomes unbearable. Below is a quick list of the interactions I could manage to create between the AIBO and other devices.

I did not manage to connect the AIBO directly to my computer, as will be explained later.

I managed quite easily to connect the AIBO to an infrastructure wireless network, using a wireless router. Therefore, I had the possibility to connect the AIBO to various devices, such as a PC, a Pocket PC and a Playstation Portable (PSP).

Connection with a PC

You can connect to the AIBO using a telnet client. The carriage return of the Windows telnet makes it really difficult to run (APERIOS, the AIBO OS is derived from UNIX), so Cygwin is suggested for the Windows users. The telnet client runs perfectly on Linux. Once you are connected, you can send a few commands to the AIBO if you have installed OPEN-R, R-Code, Tekkostu or URBI on it (using a programming memory stick). There are a few tools provided for Windows called the AIBO Entertainment Player (AEP); they provide some interesting functions such as being able to see the live stream of the built-in camera, making your AIBO speak or play a CD, seeing your AIBO's actions in 3D, making him do several movements, etc. These tools were not ported to other OS by Sony, but some developers on the web plan to do so. AIBO has a built-in web server that provides a few web pages when you try to connect to it. These pages contain the pictures taken by the AIBO, and a few other things (contained on the AIBO Mind memory stick). These pages may of course be displayed by any PC.

Figure 1.1: Representation of a connection between an AIBO and a PC running on Windows/Linux

Connection with a Pocket PC

I made tests with two different Pocket PCs:

Cassiopeia E-200F

Figure 1.2: Representation of a connection between an AIBO

and an E-200F connected to a PC via a USB link

As for the telnet client, I used the freeware CE FileCommander (see http://www.abisoft.spb.ru/products/ce_fc.html for more details). The telnet session went all right on this device, although this software does not really deal correctly with the UNIX carriage return (as the Windows telnet). The connection was possible, and sending commands and receiving the results was successful. With telnet, you can act on different programming languages previously installed on the programming memory stick, such as R-Code, or in my case URBI. As for accessing the web page, everything worked correctly with the Cassiopeia using the provided mobile version of Internet Explorer (version Pocket PC 2002). I could access all pages, and the page was shown correctly on the small screen.

IPAQ h5450

Figure 1.3: Representation of a connection between an AIBO

and a h5450 directly connected to the network

The telnet session occurred exactly as on the E-200F. The h5450 could download the web page correctly on its version of Internet Explorer (the source code of the page was complete), but it could not display it correctly (it displayed a blank page). This was surprising, as its version of Internet Explorer is more recent than that of Cassiopeia (the version of the browser directly depends on the version of the OS). I had to download Minimo, the Pocket PC browser of the Mozilla Foundation (http://www.mozilla.org/projects/minimo/) to be able to display the page correctly, and although this browser was much too slow, it could show every page perfectly.

Connection with a Playstation Portable (PSP)

Figure 1.4: Representation of a connection between an AIBO and a PSP

Using the infrastructure network, it was easy to get the pictures taken by the AIBO through its integrated web page using the PSP browser. Unfortunately, that was the best I could do. Nothing else was supposed to be possible. There was a project of adding a software similar to the AIBO Entertainment Player on the PC to the PSP, but this project was given up by Sony.

There is also the possibility to run some home-made software (commonly called homebrews) on the PSP using flaws in the operating system to run programs. These programs are totally unsupported and their use is forbidden by Sony. Unfortunately, the version of the firmware of my PSP did not allow me to run these tests. One is using VNC (Virtual Network Computing) for PC and PSP: you connect your PSP to your PC, and your PC to the AIBO using the AEP. This kind of solution is not really worth talking about.

There is also another program allowing a few interesting functions such as seeing the camera stream live; but it is not compatible with the ERS-7 (see http://www.aibohack.com/psp/wifitest.htm).

Figure 1.5: Homebrew running on a PSP, receiving the live video stream

from a ERS-220 AIBO camera

source of the picture: aibohack.com – the picture was modified in accordance with this project

There must be some other telnet client homebrew existing, but as I knew I would not be able to run them, I did not search a lot this way.

Connection with a Mac

I did not have the opportunity to use a Mac to make tests, but I had some feedback saying that the basic connections to the web page and to the telnet server work.

The ad-hoc connections

The 802.11 protocol allows direct connection from a device to another device without having to belong to a network (infrastructure mode): this mode is called ad-hoc mode or peer to peer mode. The two devices (or more) allow themselves the IPs. In spite of a lot of time spent on it, I did not manage to make this mode work with the AIBO (see http://www.premiumwanadoo.com/aibo-fr.com/forum/viewtopic.php?t=1738 – French) for more information on my work.

Figure 1.6: Representation of an AIBO directly connected to a PC (ad-hoc connection)

Another 4ICT9 student also doing a final year project on the AIBO, Richard Pollock, managed to make this connection work. So I tried to connect to the AIBO using his parameters, but it failed. I had a look at his settings, and his AIBO's configuration file (\OPEN-R\SYSTEM\CONF\WLANCONF.TXT located on the programming memory stick) has the access point mode parameter set to infrastructure mode (APMODE=1); thus theoretically, the ad-hoc network should not work.

I have had a lot of feedback from AIBO users saying that the ad-hoc functionality was badly implemented by Sony; most of them did not manage to have the ad-hoc mode work. It is also commonly believed that Sony's laptop computer (the VAIOs) are almost instantly compatible with the AIBO if you choose the ad-hoc mode. It is interesting to quote that Richard has a VAIO; as mentioned later, I have a HP Pavilion. It is impossible for me to state whether all of this is due to a misconfiguration from me or not. It is as impossible for me to prove whether these beliefs are true or not.

I also tried to connect to the AIBO from the PSP, through the ad-hoc mode, using a well known hack. When the PSP is looking for other PSP players (Game Sharing mode), it creates an open, non-encrypted ad-hoc network. If I could have managed to connect the AIBO to this network, the AIBO would have been able to try to find the PSP as the network root. Unfortunately, once again it did not work. Connecting directly the Pocket PC HP IPAQ h5450 would have been a good idea too, but the Pocket PC was not able to find the AIBO.

I also wanted to have 2 different AIBOs having the same ad-hoc parameters, thus theoretically being able to connect to each other, and after launching the program, looking for each other. Once again it did not work for an unknown reason.

For the purpose of all these tests, I coded a function that would be able to show the current quality of the signal every five seconds, using the 14 leds on the face of the AIBO. If the AIBO seems mad (red leds on), it means that the signal quality is strictly equal to 0, so we can assume that the AIBO is not connected.

As I mentioned before, only a few functions were ported to URBI. The Open-R API provided a full amount of functions and values that allow to have a complete idea of the current connection: a boolean stating whether or not the AIBO is connected to anything, a boolean stating whether or not what the AIBO is connected to is an infrastructure network (otherwise it can only be an ad-hoc network), figures representing the noise, and so on. These functions would have been more than useful to know where my impossibility to create an ad-hoc network with my AIBO came from. I found many incoherences and/or bugs in my results; I was not able to state whether it was the port of URBI that was to blame, the Open-R API or my method itself.

For more informations about the wireless implementation in AIBO, see:


Open-R SDK




Open-R documentation

\OPEN_R_SDK-docE-1.1.5-r1\Level2ReferenceGuide_E.pdf , chapter 6, pages 86-87

Open-R sample codes



URBI forum



source on the website


Figure 1.7: No ad-hoc connection was possible to realize


Universal Plug and Play (UPnP) is a set of computer network protocols promulgated by the UPnP Forum (http://www.upnp.org). The goals of UPnP are to allow devices to connect seamlessly and to simplify the implementation of networks in the home and corporate environments. A newly connected device shows its presence to the entire network when connected, and can send a list of the services it can provide.

The AIBO is UPnP compatible (although it is not certified as so), and it is implementing the Basic Device architecture (http://www.upnp.org/standardizeddcps/basic.asp). This is defined in the file \OPEN-R\APP\PC\AIBO.XML (only on the AIBO Mind Memory stick). The AIBO is recognized as a UPnP device by the network, and Windows is automatically warned of its presence. Its only aim is to provide the URL of its built-in web server to all the UPnP devices compatible in the network. This would not have been possible if the router of the network was not UPnP compatible.

AIBO has tremendous wireless connection possibilities, but unfortunately almost all of them are only accessible from the AIBO Entertainment Player on Windows. It is a shame that the enhanced functions where not implemented on other operating systems, or not documented for allowing developers to try to do so. The correct way would have been to add these functions to the built-in web page, or to provide each function as a UPnP service. By using an open standard, Sony would not have had to care about porting each function provided by the AIBO to all the existing platforms.

For example, the UPnP Digital Security Camera Device with the Still Image Service (see http://www.upnp.org/standardizeddcps/digitalsecuritycamera.asp) has to provide a still picture when asked, and has to be able to change the settings of the camera. All of this is natively provided by the Open-R API, thus trying to implement this function would have seemed a good idea. Then, the AIBO camera would have been accessible to every UPnP compatible device (TV, Pocket PC, smartphone, PC on any OS, etc.).

The Motion Image Service requires a video stream. The AIBO can provide this kind of stream, as the AEP contains a function making it possible to see what the AIBO sees live. Unfortunately, this function was not documented by Sony, so porting it to a UPnP service would need retro-engineering.

Figure 1.8: Summary of the realized connections

Chapter 2: Security

Going from wire to wireless networks changed many things, most good, some bad. In particular, it made communications sniffing more easy, which brought up some security questions. As the AIBO is potentially able to show a live video of your house, one does not want his neighbour to be able to take control of his robot when away. Is the security of the AIBO sufficient?

There are a few protections available for the wireless connection. First, the AIBO wireless card only supports a WEP encryption of 128 bits, which is commonly known to be broken for a while (as flaws where found in the use of RC4 and CRC-32). The WEP key can be set either in ASCII or in hexadecimal. Although I did not try to hack this wireless connection to the AIBO, my opinion is that if there is enough data sent and received (as when you are streaming the camera picture with AEP for example), it should not take so much time to find the WEP password. I think that trying to find the WEP password and analysing the packets (with an Ethereal-like software) would be an interesting exercise.

The AIBO also has a separated login/password protection: the owner can set a list of users and their associated password in the memory stick; thus all the functions (telnet, AEP, etc.) are password protected. I did not really study this protection. Both this password and the WEP encryption are disabled by default, and most of the time they are suggested to be disabled by users as they are difficult to install, and as it is a traditional reflex to first disable the security when you have a connection problem.

I have to add that all this information (from the SSID of the network the AIBO will try to connect to, to the WEP key and the owner's name and password) is written on files on the programming memory stick, without being encrypted. Thus if any external person has access to the memory stick, the AIBO connection to the network, and therefore the network's protection itself might be considered as broken.

In addition, you can of course use some additional protection to your infrastructure network (hidden SSID, MAC address filtering, limitation of the number of IP given by the DHCP server, etc.). The AIBO is compatible with all of them, although that this protection will not prevent someone motivated enough to be able to connect to your network. These measures will not replace a good encryption security.

Furthermore, many users lower the security of their own network so that the AIBO can connect to it. Most of the current routers are WPA2/802.11i compatible. Having your AIBO connected makes reducing the encryption to WEP necessary, and consequently makes the whole network's protection almost non-existent. The ERS-7 began to be shipped in Japan in September 2003. Certifications for implementations of WPA started in April 2003, so implementing a secure enough encryption protocol was not really possible for Sony, although they could have done it in the Open-R SDK's updates or on the Mind updates.

As a conclusion, although I did not do robust testing, I would say that the security of the wireless connection of the AIBO is far too low. Most of the AIBO owners consider it as a real pet, and therefore would never disable it. The AIBO would disable itself automatically when it is “tired”, would go charge itself automatically, and would awake by itself. Leaving your AIBO on to allow it to play by itself is part of the AIBO Mind evolution process. Therefore, anyone might take control of your AIBO at any time of the day. As the 802.11b protocol allows a range of 100 meters, anyone in the range might take control of your AIBO, being able to hear what it hears, being able to move all around the area and record the live video stream without the owner even being aware of it (the AIBO behaviour would be considered as the normal AIBO Mind behaviour).

Chapter 3: Sniffing algorithm

In this chapter, after a short review of the work throughout the year, there will be a description of the sniffing algorithm and its different evolutions, followed by a criticism of the result.

Project Review

The theme was chosen around the end of October. The idea of a 802.11 sniffer was suggested, but we decided to wait a bit for analysing whether it was the best idea or not. I started to work a bit around the AIBO, looking for some information on the net, reading the documents, trying to find the best programming language, trying to figure out the possibilities and the limitations of the AIBO, etc.

I started to work again in mid-January, trying the most basic languages for the AIBO (R-Code and Yart), coding directly on the programming memory stick. At this time, the telnet would not work (as I tried ad-hoc connections only), so programming and debugging was very slow. Then, from mid-March, I started to work on the project full time. Soon, the limitations of Open-R made us understand we had to reconsider our initial idea. We discovered that the only network the AIBO can connect to has to be previously defined by modifying a text file on the memory stick. Therefore, the AIBO cannot change networks without being disabled. We decided to work on an algorithm that would allow the AIBO to find the access point to which it is connected.

There are lots of Software Development Kits (SDKs) freely usable on the net. The most famous are:

All these languages are based on Open-R, that is to say that they use the Open-R API.

At first, I tried R-Code; I used it for understanding the different parts of the AIBO, and testing the connection between my PC and the dog. But I knew it would not be adapted to my needs. Obviously, Open-R was far too low-level considering the amount of time I had for my project. Then, I had the choice between Tekkotsu, URBI and Pyro. As I did not know Python, this last choice was soon forgotten.

I had a lot of good feedback on URBI on the French forums. So I asked whether URBI could or could not deal with the wireless card values on the URBI official forum. As an answer, Mr. Jean-Christophe Baillie provided me a nightly build version of URBI he coded specially for me, adding support for some part of the Open-R API dealing with wireless. In the meantime, I was testing the different connection possibilities with the other devices, frequently finding new ideas to make some connections work. Finally, after the project presentation in early April, I made the last few connection tests, implemented the last ideas in the algorithm, and wrote my report.

Description and evolution of the algorithm

The basic idea was very simple: the AIBO would be able to record a measurement of the quality of the signal at every moment, and using a gradient, find the source of the signal. The original algorithm was based on a hexagon tessellation of the plan: the plan would be divided into hexagons (as an area is paved), and the AIBO would move from the centre of one hexagon to another, according to the quality of the signal of these centres.

Figure 3.1: Description of the idea of the original algorithm

It is really easy to display in live the signal quality using URBI (just by typing #graph wlan.signal;). Trying to study the variations of the signal, I quickly found a very interesting result: the effect of the variation of the orientation of the AIBO is much more important than the effect of the variation of the distance. This might be explained by the fact that the AIBO's body is full of metallic parts, although this is just a hypothesis. Thus, it became possible to introduce a logical feature into the algorithm: the AIBO would measure the quality of the signal at a few orientations, and deduce the direction to take. The idea would be to measure the quality at 0°, 72°, 144°, 216° and 288°, which would represent the five sides of a pentagon. After having recorded the five different measurements by doing a complete turn, it would simply have to turn again in the direction in which the measurement was the best.

Figure 3.2: Description of the 5 different orientations

For example, the AIBO would start at the orientation 0°, and record all five measurements. It might find that the direction to take is 216°, therefore turning 144° on the trigonometrical way. In reality, as the wireless sensor is located on the rear part of the AIBO, the AIBO would have to go to the opposite direction of the best recorded value. But this is based on the idea that turning 72° five times would bring the AIBO to its starting orientation, which is only possible if the turning algorithm's precision is good (an imprecision of less than ± 8° after turning 360°, that is to say of at least ± 2%).

My program uses many functions already provided by URBI, such as getting up and standing at boot time, walking or turning. The basic function for turning was based on the duration of the turn, using a standing turn. After a while, I found another algorithm based on the angle of the rotation, using a crabwise rotation, which had the advantage of being both faster and more precise. Unfortunately, both these functions have an imprecision of far more than ± 10%. So basing an algorithm on the idea that the accuracy of the rotation's angle is good enough became impossible.

However, if the AIBO could not find the absolute minimum for each direction, it could still find a local minimum. That is to say that, at a stated position, supposing the AIBO has recorded a few values at the previous orientations, and that the current orientation's value is inferior to all the previous values, the current orientation is a local minimum. We can therefore consider that the rear part of the AIBO is more oriented to the opposite direction of the waves source than it was in the previous few orientations. So, we can consider that the head of the AIBO is closer to the access point than it was before; thus, by walking a bit, the AIBO would get closer to the access point. The algorithm was eventually based on this supposition. Although this remains an approximation, it seemed a reasonable way to be able to choose a direction with so few and non-precise information.

Figure 3.3: Example of four signal qualities recorded, the fifth being a local minimum;

the angles on this figure were drawn different on purpose

The AIBO would turn until the current value is inferior to the last few values (for example the last recorded values). Then, it would walk a bit (not more than ½ meter), and look for the good direction again, several times until the signal quality is considered as good enough (a quality of more than 0.75 is considered as very good); the AIBO would thus be considered as close enough to the access point, and stop.

At the same time I had to face some other kinds of problems: measurement problems. At first, it seemed that the values where not at all in accordance with the orientation, and that they were totally random.

Figure 3.4: Graph representing a typical signal quality variation during three measurements

So quite naturally, instead of considering that an instant value represents the exact signal quality at a given orientation, I implemented a mean algorithm. The mean of a few measurements taken every half second would represent the value I was looking for. I also added a small temporizing after the rotation, so that I would avoid taking into account the typical noise values that always occur at this part (see Figure 3.4).

Another problem was that sometimes, for an unknown reason, the measurements where very scattered; thus it was very difficult even by seeing the set of measurements to determine what would be the most accurate value to represent the set. The calculated average would at this time have no meaning. Thus I implemented a function calculating the standard deviation. If the standard deviation is too high, then the robot would move a bit to the right, move a bit to the left to approximately come back at the same place, wait for 5 seconds, and start making a new set of measurements again. I also sometimes had temporary deconnections: the values measured started to be null in the middle of the measurements. Calculating the standard deviation also avoids concluding that a value is lower than it is in reality because a deconnection reduced the calculated average (see Figure 3.5). Sometimes, in spite of giving an accurate set of values, the AIBO would measure extremely low signals, in spite of being close to the access point. It was possible, by seeing the set, to see that these measures did not reflect the probable value. So in order to take this into account, if the mean was too low, the AIBO would do the same operation which is done when the standard deviation is too high: it would move a bit to the right, come back, wait for a few seconds, and start another set of measurements. This would also help preventing the temporary deconnection problem (see Figure 3.6).

Eventually, sometimes, the AIBO was in a problem state several times in a row. That is to say that either the standard deviation or the mean value made it think that the measurements taken were not reflecting the reality. This could happen either because the AIBO was too far from the signal source, or because the measurements are inherently subject to high imprecision. Most surprisingly, it happened most of the times when the AIBO was well oriented, that is to say when the rear part (where the wireless card is situated) was on the opposite direction from the access point. That is why I chose that if a problem state occurred 3 times in a row for a stated orientation, then the AIBO would go forward as if it found a local minimum. This choice was made both based on the idea that it seemed most of the time an accurate choice, and because in the infrequent cases it was not, there was no other choice the AIBO could guess easily without having to restart making a full load of measurements.

Figure 3.5: Graph representing a very scattered set of measurements

Figure 3.6: Graph representing a deconnection leading to an inaccurate average

Result and limitations of the algorithm

The result varies a lot considering the type of environment. In a wide space without any furniture or walls, and having a very strong signal (with an external antenna for example) without interference, the result is, as a matter of fact, much better than in a narrow room full of obstacles, with a router providing a weak signal. In optimal conditions, it usually takes the AIBO from one to five minutes to find an access point originally located less than 5 meters away. But in bad conditions (the conditions in which most of the tests were made), although the result is good enough most of the time, it sometimes took the AIBO more than 10 minutes to find the target (at this time, the AIBO automatically stopped, and we considered that the research failed).

Considering the choice of the programming language, it is a fact that URBI helped me to be able to start coding at once with expanded possibilities. I saved a lot of time compared to what it would have taken me using Open-R. The documentation around URBI is very complete, and easy to read. My choice was oriented by a URBI fan community, which promised to help me. I am nevertheless very upset by the fact that the only thing the URBI community provided me with was the nightly build version of URBI. I had to face numerous bugs and problems and an incomplete implementation of functions which would have been really useful to me. I reported many bugs and problems, tried to be as helpful as possible, and wrote a consequent amount of feedback without any correction in return. I was told that the bugs were unimportant, and (a bit too late) that URBI was still in beta version.

Even though URBI is a very good programming language for the beginner, I would, for these reasons, unadvise its use for any serious project. Tekkotsu, which has stood the test of time, might be an interesting alternative.


As demonstrated, the numerous capacities of the AIBO allows one to make many ideas a reality. The original goal of this project was mostly fulfilled after a while. Although the result is acceptable, we have not reached the best possible one, which leaves a possibility of improvement.

Improving the algorithm might be done by:

Considering the interactions between the AIBO and some other typical home network devices, some exist, but we can regret that most are insufficient (as Sony did not document the connection protocol between the AIBO and the AIBO Entertainment Player), even with others Sony devices.

On the 26th January 2006, Sony announced that it would discontinue AIBO and several other products. It will also stop development of the QRIO robot. Although AIBO will still be supported until 2013, many users feel betrayed by Sony. The insufficient security will not be completed by Sony, and the AIBO will not be made compatible with last generation devices. This will most probably put an end to the entertainment life of the AIBO, but one can be sure that it will remain the traditional and appreciated research and studying tool for a long time.

Tools used

AIBO ERS-7 with Mind 2 Service Pack 3

Memory Stick Sony M OPEN-R 16MB AIBO / ERA-MS016 (programming memory stick)

Memory Stick Sony M OPEN-R 32MB AIBO MIND 2 / ERA-MS032

PC: laptop HP ZD7012EA running on Windows XP Pro SP2 and Mandriva 2006 (Linux)

integrated memory stick reader (ENE PCI Memory Card Reader Controller)

external PCMCIA Wireless Card (Freebox card WPCB-104GB, Broadcom chipset)

external USB Wireless Card (D-Link DWL-122)

Pocket PC:

Playstation Portable (PSP), running on the firmware version 2.70

Router: BeWAN ADSL 600W

URBI version v0.9.8c build295 based on OPEN-R SDK v1.1.5 r5

Report written with OpenOffice.org v2.0.2 Writer

Slides done with OpenOffice.org v2.0.2 Impress

Graphs done with Microsoft Office 2003 Visio

Web page done partially done with Nvu v1.0

Pictures done with The Gimp v2.2.10, Paint.NET v2.61 and Inkscape v0.43


Report, slides and program source code:




AIBO website:


Open-R website:



Appendix A: commentary on the program

I did not comment directly in the code as I discovered a bug in URBIlab (the client software to the URBI core, running on the AIBO); some comments seem to block the software (see http://www.premiumwanadoo.com/aibo-fr.com/forum/viewtopic.php?p=24356#24356 – French). I reported this unknown bug, but as the people that developed URBIlab left the URBI team, correcting it is not a priority for them.

As URBI is a script language, you can code it with any text editor. It lacks a real editor to help you by automatically indenting the code, having a syntaxic colouring function and helping you to debug, etc. That is why I suggest using any advance editor, as Kwrite on Linux (http://en.wikipedia.org/wiki/Kwrite) or Notepad2 on Windows (http://www.flos-freeware.ch/notepad2.html), which both provide syntaxic colouration (as URBI did not provide any grammar, I suggest using Python syntaxic colouration).

I tried but did not manage to automatically colour the code I provide here, my apologies for the reader.

As the program can be run on stand-alone (that is to say without a computer connected to the AIBO to monitor in live the signal quality values, and the AIBO's decisions), I tried to show this information also by playing some sounds using the built-in speaker in the AIBO, and by trying to display on its face (using the colour leds) a “mood” that would be accurate to the current situation. For example, when the AIBO faces a problem (e.g. inaccurate values), the algorithm switches on the red leds; when the AIBO found the good orientation to go, the algorithm switches on the green leds, and so on.

To be able to run the software correctly, you have to copy some wave files on the root folder of the programming memory stick. I copied these files directly from Windows XP. Here is the table of correspondences:

wxcs.wav → %windir%\Media\Windows XP Critical Stop.wav

wxer.wav → %windir%\Media\Windows XP Error.wav

wxex.wav → %windir%\Media\Windows XP Exclamation.wav

wxpc.wav → %windir%\Media\Windows XP Print complete.wav

Never use a file name with a space in it; the Open-R API does not seem to deal with it correctly, so as a consequence URBI does not either (although this is not written anywhere in the documentation provided; see http://forum.gostai.com/viewtopic.php?t=129 ).

Some functions and variables used in my code (as walk.turn(angle), walk.go(distance) and robot.stand()) are also defined in the code provided and automatically loaded in URBI.

You have to copy Gilles.u at the root of the programming memory stick, and load it in any file (as for example URBI.INI or custom.u) by adding the line load(“Gilles.u”);.

There might still be French parts in my code, or any other kind of mistakes. The indentation might not be perfect (I had to do it manually). I apologize in advance if it was the case.

My code (that is to say the file Gilles.u) is under the GPLv2 licence (see http://www.gnu.org/licenses/gpl.html for more informations). The Open-R SDK's licence is different from the GPL. You can use it freely for non-commercial use only.

For more information, see http://www.premiumwanadoo.com/aibo-fr.com/forum/viewtopic.php?t=1504 – French or http://openr.aibo.com/openr/en/viewtopic.php?t=282 ; http://openr.aibo.com/openr/en/viewtopic.php?t=252 - English). URBI may also be used only for non commercial purpose.

The function max(my_list) returns the index of the maximum in this list.

The function min(my_list) returns the actual minimum value of the list.

The function standard_deviation(my_list, my_mean) returns the standard deviation of a list which mean was already calculated and is provided.

URBI ported 2 values provided by the Open-R API; the signal quality (wlan.signal) and the signal noise (wlan.noise, probably the SNR). The wlan.signal value is constantly variating, but the wlan.noise value seems to be constant (see http://openr.aibo.com/openr/en/viewtopic.php?t=299). In fact, it seems to stay constant once the AIBO is booted, and the value does not change until the AIBO is rebooted. Therefore I made a few tests:
I booted my AIBO on a very noisy (in term of waves) environment, and the noise given was high. I brought my AIBO far from this noisy environment, the value given was still constant. I rebooted it, the new value was low. I brought it back to the noisy environment, the value was still low, till I rebooted, and the value became high again. I tried to run a testing program on Open-R to see whether it is Sony's implementation that has a problem, or URBI's (see http://www.premiumwanadoo.com/aibo-fr.com/forum/viewtopic.php?yp=24883#24883 and http://www.premiumwanadoo.com/aibo-fr.com/forum/viewtopic.php?t=1802 – French). Unfortunately, I did not manage to make this program run, so I did not figure out where the problems came from.

The checknoise(waiting_time) function is made to compare every few seconds (waiting_time parameter) the current wlan.noise value to the one at boot time, and showing a message if these values do not match. As a matter of fact, this message was never displayed. Once this function is called, it never stops, and the rest of the program turns in parallel.

The function measure(number_of_measures, start_waiting_time, waiting_time) is made to provide a good approximation of the quality of the signal at a given orientation. As explained in the algorithm description, after rotating, the AIBO will wait for 1 second (or any time set by the parameter start_waiting_time), and record 10 values, each measurement separated by half a second (these 2 parameters can be modified changing number_of_measures and waiting_time).

The function ears_movement() moves happily the ears of the AIBO when the program starts, to show that the AIBO is ready to go.

The function searching(minimum_signal_quality_required, number_of_values_remembered) makes the AIBO register a few measures, trying to find the access point to which it is connected, and walk in its direction. See the algorithm description for more informations. As described previously, the algorithm is looking for a local minimum. It compares the current orientation signal quality to the 5 previous ones (this can be set modifying the number_of_values_remembered parameter). This function stops if the signal quality is considered as being good enough (more than 75%, or any value set by the parameter minimum_signal_quality_required).

The function gillesdemo() gets the AIBO ready, and launches a search of the access point. To launch this demo, either connect to the AIBO via URBIlab and type gillesdemo(); or touch the three sensors on the back of the AIBO simultaneously (the AIBO does not need to be connected to any device for launching the program, but it sends a log that allows to see continuously what he is doing, and where he is in the algorithm). If after 10 minutes the search was unsuccessful, it stops automatically.

The function quality_of_signal() displays on the head of the AIBO the current quality of the signal every few seconds. This is particularly usefully when you are not connected to the AIBO, and thus you cannot echo the values to URBIlab. This function was only used for testing purpose, especially during the ad-hoc connection tests. This function ends by itself after 2 minutes.

Appendix B: the source code of the program: Gilles.u


* W/BO Project Wi-Fi over AIBO

* Author: Gilles RÉANT - 2005/2006

* GPLv2 licence http://www.gnu.org/licenses/gpl.html

* see http://macneill.cs.tcd.ie/~reantg/WIBO_Project/

* or http://www.reant.net/tcd/WIBO_Project/

* for more informations


echo "Defining functions & variables";

global.default_noise = wlan.noise;

def max(my_list) {

maximum = -1;

index = -1;

i = -1;

foreach n in my_list {


if (n > maximum) {

maximum = n;

index = i;



return index;


def min(my_list) {

minimum = 99;

index = -1;

i = -1;

foreach n in my_list {


if (n < minimum) {

minimum = n;

index = i;



return minimum;


def standard_deviation(my_list, my_mean) {

result = 0;

foreach n in my_list {

result = result + (n - my_mean) * (n - my_mean);


result = sqrt(result);

return result;


def checknoise(waiting_time) {

loop {

if (wlan.noise != global.default_noise) {

echo "Wow, the noise is original!! " + wlan.noise + " (instead of default " + global.default_noise + ")!!";





def measure(number_of_measures, start_waiting_time, waiting_time) {

ok = false;

number_of_problems = -1;

while (!ok) {

number_of_problems = number_of_problems + 1;

if (number_of_problems == 0) {

ledF1 = 0;

ledF2 = 0;

ledF13 = 0;

ledF14 = 0;

global.ledMode = 0;


if (number_of_problems == 1) {

ledF13 = 1;



if (number_of_problems == 2) {

ledF14 = 1;



if (number_of_problems == 3) {

global.ledMode = 1;


echo "/!\ We had measurement problems 3 times in a row, so forward!";

return -1;



mean = 0;

my_list = [];

for (i = 0 ; i < number_of_measures ; i++) {

current_signal = wlan.signal;

mean = mean + current_signal;

my_list = my_list + current_signal;

echo "measure[" + i + "]: signal=" + current_signal + "; mean=" + mean/(i+1);

if (i < number_of_measures - 1) {




mean = mean / number_of_measures;

ecart_type = standard_deviation(my_list, mean);

echo "for information: mean=" + mean + " standard deviation=" + ecart_type;

if (ecart_type > 0.1) {

echo "The standard deviation is too high (>0.1). We are going to make another set of measurements after moving a bit.";

ok_1 = false;

} else {

ok_1 = true;


if (mean < 0.05) {

echo "The mean (" + mean + ") is inferior to 0.05. We are going to make another set of measurements after moving a bit.";

ok_2 = false;

} else {

ok_2 = true;


ok = ok_1 && ok_2;

if (!ok) {






return mean;


def ears_movement() {

earR->blend = queue;

earL->blend = queue;

loopn(5) {

earR = 0;

earL = 0;


earR = 1;

earL = 1;




def recherche(minimum_signal_quality_required, number_of_values_remembered) {

current_signal_quality = wlan.signal;

while (current_signal_quality < minimum_signal_quality_required) {

my_list = [];

forced_forward = false;

loopn(number_of_values_remembered) {

if (!forced_forward) {

variable = measure(5,2s,0.5s);

if (variable == -1) {

echo "forward!";

forced_forward = true;


if (!forced_forward) {

my_list = my_list + variable;





if (!forced_forward) {

echo "Measurements done!";

echo "List: ";

echo my_list;

minimum = min(my_list);

echo "Minimum: " + minimum;

variable = measure(5,2s,0.5s);

if (variable == -1) {

echo "forward!";

forced_forward = true;


if (!forced_forward) {

while (variable > minimum) {

echo "The current value (" + variable + ") isn't inferior to the minimum (" + minimum + ").";

new_list = [];

i = 0;

foreach n in my_list {

if (i != 0) {

new_list = new_list + n;




new_list = new_list + variable;

my_list = new_list;

echo "New list: ";

echo my_list;

minimum = min(my_list);

echo "New minimum: " + minimum;


variable = measure(5,2s,0.5s);

if (variable == -1) {

echo "forward!";

forced_forward = true;



echo "Cool! :D I have a value of " + variable + " inferior to the minimum " + minimum + ".";


} else {

echo "Cool! :D I have a value of " + variable + ", so forward.";


ledF1 = 1;

ledF2 = 1;



current_signal_quality = wlan.signal;


echo "We have reached a quality of signal of " + current_signal_quality + "!";

echo "End of the program.";


def gillesdemo() {

ledBFC = 1;

ledBMC = 1;

ledBRC = 1;

echo "Gilles start - W/IBO project ; Wi-Fi over AIBO";

echo "My name on the network: " + wlan.stationName;

echo "I'm on channel " + wlan.channel;

echo "WLAN noise (constant value; bad implementation?): " + wlan.noise;


echo "I'm connected on the network " + wlan.ssid;

echo " but I can't tell whether it is an ad-hoc or infrastructure network. :-(";

motor on;

echo "Motors on";

echo "Getting up";


neck = 2 & ears_movement() & tailPan = 0 speed:20;


echo "OK, I'm ready";

timeout (10m) recherche(0.75,5);


def quality_of_signal(total_time, waiting_time) {

ledF = 0;

timeout (total_time) loop {

ledF = 0;

current_signal_quality = wlan.signal;

echo "signal quality (0.0 - 1.0): " + current_signal_quality;

ledF13 = (current_signal_quality == 0);

ledF14 = (current_signal_quality == 0);

ledF1 = (current_signal_quality > 0.08);

ledF2 = (current_signal_quality > 0.16);

ledF3 = (current_signal_quality > 0.24);

ledF5 = (current_signal_quality > 0.32);

ledF12 = (current_signal_quality > 0.40);

ledF6 = (current_signal_quality > 0.48);

ledF4 = (current_signal_quality > 0.56);

ledF7 = (current_signal_quality > 0.64);

ledF9 = (current_signal_quality > 0.72);

ledF11 = (current_signal_quality > 0.80);

ledF10 = (current_signal_quality > 0.88);

ledF8 = (current_signal_quality > 0.96);





at((backSensorF > 10) && (backSensorM > 10) && (backSensorR > 10)) {



Appendix C: my wireless configuration file: WLANCONF.TXT

# author: GILLES :-)


# infrastructure working, no ad-hoc working

# using the router BeWAN ADSL 600 W

# more infos on this file at

# http://www.premiumwanadoo.com/aibo-fr.com/forum/viewtopic.php?t=1095

# http://openr.aibo.com/openr/en/viewtopic.php?t=246

# \OPEN_R_SDK-docE-1.1.5-r1\InstallationGuide_E.pdf page 10








# 0=ad-hoc ; 1=infrastructure ; 2=inf || ad


# no need to specify the channel on infrastructure mode



# IP network









# SSDP - for UPnP



Gilles RÉANT 49