AIBO Frequently Asked Questions

(and some that aren't, but should be)

Index

Robot Issues

1. Nothing moves!

Run through this checklist:

Does the AIBO work without a memory stick?
- No: battery or other hardware problem
- Yes: Memory stick problem:
- - Are you using a "fresh" pink memory stick? Purple memory sticks will not work, and neither will overwritten AiboMind sticks, even though they are pink (copy protection scam, errr "scheme")
  - Your memory stick's file system may have been corrupted, often by a crash while writing to the memory stick, or by pulling it out of the drive while its in use. Try deleting all the files on the stick, run Windows' "Scan Disk" or Linux/Mac's fsck.msdos to fix the format. Do not reformat -- this might delete hidden copy protection information, rendering the stick useless. Isn't DRM wonderful?
  - If this problem recurrs, try a different brand of memory stick reader. Non-sony brand readers have been reported to not handle DRM-enabled (pink) memory sticks correctly, thus deleting the secret bits. We've had success with Dazzle and SmartDisk, but some limited (not permanent) trouble with SanDisk. Or be safe and spend 4x as much for a Sony drive. Yay DRM!
Does the AIBO crash (plays some unhappy notes)
- If this happens before the 'click' of motor power being turned on, it's a low battery
- If later in the boot, may be some kind of initialization error
- - Wait until the power-on click
  - Repeatedly try to telnet to port 59000 until connection is made
  - Try to find suspicious error messages in the output
Does the AIBO eventually make a growling noise?
- No: Double check you have the right TEKKOTSU_TARGET_MODEL setting in your project's Environment.conf file.
- Yes: Good! Boot sequence has completed. Read on.
Are the LEDs flashing rhythmically?
- The Emergency Stop is on by default after boot. This is to prevent the robot from making any unexpected motions upon first booting up. To release the emergency stop, double tap the center back button, or press the "Go" button in the Controller GUI. The robot should bark. To freeze the robot again, either double tap the back button again, or press the "Stop" button in the Controller GUI. This time the robot will make a screeching sound.
- To permanently disable the startup in emergency stop feature, you will need to edit the StartupBehavior.cc file in your project directory.
- There's also a video and more information about the EStop.
If all else fails, try a precompiled binary memory stick from the Downloads page.

2. It stopped sending text to port 59000, or some text doesn't appear...

If you output too much before you connect to 59000, you can overflow the comm buffer and any further outputs are ignored (even after you connect - you just get everything up to the buffer limit.)

Interestingly, printf and cout seem to have separate buffers, so cout may die off, but printf's will still work.

All you have to do is just connect to 59000 earlier on... the buffers aren't particularly small, so this doesn't happen very easily.

Also, since port 59000 is buffered, if the Aibo crashes, you might not receive some of the last lines that were output because they hadn't been flushed yet.

3. How can I plug in the power adapter without shutting down?

Once upon a time, you could plug the power adapter (shown at right) into your ERS-2xx series Aibo and it would continue running just fine. This is really handy when you're debugging communications type stuff and all the Aibo is doing is just sitting there. Not only does it keep the battery from draining, but it will recharge the battery while running. You can also swap batteries if you don't want to lose whatever's in memory, but want to run untethered again afterward.

Unfortunately, recent versions of the SDK will force a shutdown whenever external power is connected, which overrides our own software. To get around this, you need to put a piece of tape over one of the connectors of the power socket. This will allow power to flow, but prevents the Aibo from shutting down.

Take heed, however, that I don't know if there's a good reason why Sony decided to force a shutdown on power connection, and I don't really know what the full purpose of that connector is, so I don't know what side effects it may have. If you know the answers to either of these, feel free to let us know.

On the up side, we've been using this trick for many months now without a hitch. Also, make sure the round connector that goes into the head of the power adapter is pushed in snug - ours has a tendancy to pull out a little and disconnect without appearing so.

4. I keep getting unexpected shutdowns on my ERS-7 (Jam Condition)

This is a problem mainly for RoboSoccer teams who want to push the limits of their robots. However, at times the ERS-7 does seem overly sensitive to getting its joints locked up. There is a way to raise the error threshold:

The newest OPEN-R SDK (1.1.5) contains a feature called "Jam Detection High Threshold". If you are finding that the jam detection routine is too sensitive, you can make it less strict by creating the file "/OPEN-R/SYSTEM/CONF/VRCOMM.CFG" and writing a single line, "JamDetectionHighThreshold" in the file.

This only works with ERS-7.

Thanks,

OPEN-R SDK Support

(quoted from the OPEN-R SDK BBS)

GUI Issues

1. Determining the internet (IP) address at run time

Commonly, most networks hand out IP addresses dynamically through a protocol known as Dynamic Host Configuration Protocol (DHCP). That's great, except when you're trying to use a robot which doesn't have a built in text display to show its current IP address.

In the long run, the easiest way is to fix this is to assign an address yourself -- most wireless access points (WAPs) can be configured to hand out a pre-determined IP address to a specified MAC address, which is printed on the underside of your AIBO. (for ERS-7 models; the 2xx series have it printed on the wireless card that is plugged into the interior slot) Of course, each WAP manufacturer has its own configuration interface, so you'll have to consult your manual for help with this.

In the short run (or if your local network administrators won't reserve an IP address for you) we have a behavior which will speak the IP address to you. "FlashIPAddrBehavior" is launched at boot, and can be found under the "Background Behaviors" menu in the Controller (once you get connected that is ;)

To trigger the report, turn off the e-stop (double-tap the back button), and then press and hold the chin and head buttons for two seconds. The AIBO will then begin speaking the IP address, and will flash the numbers on its LEDs as well.

If you are going to be working in a dynamic environment, you will probably want to customize the flash_on_start and flash_bytes configuration parameters of <project>/ms/config/tekkotsu.cfg, which will the automatically report the IP address at boot and only report the variable part of the address (most of the time, all addresses within a network will share a common prefix).

2. I can't connect over the network

First use the 'ping' command line utility to try to contact the Aibo using its IP address as given in the previous item. If that fails, there is a configuration problem in the network, either with a firewall or bad ms/open-r/system/conf/wlandflt.txt settings. If the Aibo's IP address starts with 169, it is a self-assigned address and indicates that it was unable to contact a DHCP server, possibly because it was unable to join the wireless network.

If ping works, but some other functionality does not, check your firewall settings. The camera streams can use either UDP or TCP transport, but by default use UDP for better performance. Some firewalls are more restrictive of UDP usage. All other included network code uses TCP as its transport.

3. My ControllerGUI script wasn't saved

You'll need to close the ControllerGUI window for it to save the preferences. Killing its process will lose changes made to preferences.

This means that you need to click close button for the window -- pressing ctl-C from the command line or cmd-Q from OS X will kill the process before it has a chance to save current preference information

Alternatively, patch the code to save preferences after every modification, and send it in ;)

4. How can I edit the walk? Can I change more than one item at a time?

Within the Walk Edit menu, when you select one of the value controls (say for instance, "Slow Motion") type a value into the input field and hit enter. The value will be set to what you typed.

Now get this: if you select more than one item (hold down the control or shift keys) and then you enter a value, you'll update the whole set of items at once!

5. How can I dynamically change configuration parameters?

You can use the '!set' command at the ControllerGUI input field or the Tekkotsu console to change any item listed in the config file. This is handy for items that don't have a GUI to control them.

For instance, if you want to select a single image channel to be transmitted to the VisionGUI:
!set vision.rawcam_encoding=y_only
or if you want to change the resolution that the color channels are transmitted at:
!set vision.rawcam_uv_skip=3

However, some objects only check the config parameters when they are initialized, and so must be restarted for the changes to take effect. This can be done automatically, see DynamicConfig.

6. Wow, the ControllerGUI input field has a history?

That's right Virginia! There is a history! Just hit the up arrow, like any good shell ;) The last 20 commands are even remembered in the preferences from session to session, so don't go typing any passwords...

Development

1. It crashed! Can I find out where it crashed?

After the Aibo finishes beeping and shuts off, remove the memstick and put it in your drive.
From within your project directory, run the crashDebug tool:
<Tekkotsu>/tools/crashDebug

There are several options which you can pass to crashDebug to streamline the output or get extended information if the stack has been corrupted (by, say, a buffer overrun). Pass -h to crashDebug to get usage information.

If you are getting confusing or incomplete results, you may wish to try turning off some of the compiler optimizations. In the project's Makefile, try removing the -O2, -frename-registers, and -fomit-frame-pointer flags from the CXXFLAGS variable.

Stack traces provided by Mi-Pal tools from Griffith University. Thanks!

2. What events are available for my code to listen for?

The enum EventGeneratorID_t holds all of the generator IDs. This is contained in the EventBase class. Thus, for example, the vision generator is EventBase::visionEGID.

3. How do I make my behavior generate events?

If you want to throw an event under a pre-existing generator, the answer is easy:

erouter->postEvent(gen_id, source_id, type_id, duration);
erouter->postEvent(gen_id, source_id, type_id, duration, name, magnitude);
erouter->postEvent(new EventBase(...));

These functions are defined in EventRouter - you can read more about them there.

However, if you want to create a new generator, you will need to modify Events/EventBase.h and Events/EventBase.cc. The modifications are easy however - simply add a new entry in EventGeneratorID_t and give it a corresponding name in EventGeneratorNames. Once the new generator has an ID number and name, you can use it however you like.

In the future, we may try to allow dynamic declaration of generators so that modification of the framework source won't be necessary...

4. I want to compile faster (and I have a cluster of fast Linux boxes)

You're in luck! Alok Ladsariya (alokl at andrew dot cmu dot edu) happened to write a script to distribute computational tasks over a set of machines for doing a project for one of his classes, and he has donated the script to us. This is a fairly advanced topic, and requires some solid understanding of Linux features.

You'll need:

"Trusted host" ssh access from the user node to the cluster nodes (so it won't constantly ask for passwords as the jobs are distributed)
Shared mounts (e.g. NFS) to hold the framework and project (or just project if the framework isn't being modified)
OPEN-R SDK installed at the same path on each machine

Copy tools/dist_hosts.txt to your project directory. Modify the hosts shown in this example file to correspond to your local machines. Priority corresponds to the 'nice' level (if these are your dedicated machines, probably shouldn't be so nice. The default, 17, is pretty nice - suitable for shared machines) If the Force column is zero, the machine's load will be checked before each job to make sure it's not running a process for someone else at high load. You shouldn't force if you're nice - you might not get very many cycles and it'll take longer overall to finish because everything is waiting on that one job.

The user node won't be given jobs to do (other than managing the cluster nodes) unless you explicitly list it in the dist_hosts.txt file.

The setting for TEKKOTSU_ROOT and OPENRSDK_ROOT on the user node must correspond to the appropriate locations on the cluster machines as well... the same path is going to be used for execution of binaries regardless of which machine the command is being sent to.

Once all the configurations have been made, most compilation of code will be split across the cluster. Here's the basic list of the process:

User node generates stub files (very fast)
User node builds tools (not so fast, but harder to distribute)
User node builds dependency (.d) files (very fast)
User node creates <project>/build/joblist.txt, which contains compilation commands for each source file which needs to be compiled.
User node then farms out joblist.txt to cluster machines - each machine gets one line from the file to execute.
User node links together object files, produces executable in <project>/ms.

So, only the compilation of the framework and project are distributed - the tools are locally compiled. Using five 2.4 GHz Pentium machines, here's some timings:

	Clean Compile: (73 source files)	Medium Change: touch VisionEvent.h (17 source files)	Small Change: touch ChaseBall.h (2 source files)
1 machine	263 sec	97 sec	43 sec
5 (public) machines	134 sec	51 sec	37 sec
Speedup:	1.96	1.90	1.16

Remember that a clean compile has to build all of the Java tools, so there's more significant overhead than is found in the other two. Also, since the user node has to do all the linking, there's still significant overhead involved even with a small modification - when only two source files need to be recompiled, only a few seconds are saved.

However, these tests were done on shared machines with high 'nice' and no forcing. If you have dedicated lab machines, you can probably get more of a speedup than shown here.

5. Do I really need to take the memory stick out? Can't I just upload the new code?

Yes. If you prefer to upload new binaries, try out the ftpupdate and ftpinstall scripts in tools. ftpinstall is from Sony's sample code, and ftpupdate is a modified version that will only upload files which have changed since the last ftpupdate. The Aibo will even automatically reboot after the update! (and reboots are actually slightly faster than regular boots, so you might save some time there as well)

However, obviously the Aibo must still be running for this to work. (i.e. didn't crash)

If you have trouble with ftping, double check your firewall settings... (not that I didn't waste a couple hours because of that once... errr... )