Run through this checklist:
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.
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.
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)
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).
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.
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 ;)
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!
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.
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...
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!
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.
If you want to throw an event under
a pre-existing generator, the answer is easy:
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...
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.
| 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.
Take a look at the CVS usage page for instructions.
There's instructions at the top of
the page for a cvs checkout. If you're on a *nix system, you can
probably just copy and paste that to get the latest source. Then
you just need to type:
cvs update -d -P
to keep it up to date.
We will try to update documentation
on the web server at http://tekkotsu.no-ip.org/
to correspond to changes made in CVS. Thus, if you're installing
from CVS, follow the installation directions on that site and use its
doxygen source reference. (which should be automatically rebuilt within
10
minutes of every checkin)
Also, check out our Yahoo group, tekkotsu_dev, for news and communication.
Take a look at the todo list at the
top of the Version
History.
The items in the wishlist at the top are up for grabs, and you may also
want to look at unfinished items for the next release through the
bugzilla links. If you see something you want to work on, just
put a comment in the bugzilla entry so everyone else will know not to
duplicate the effort.
Whenever you're ready, see the instructions
for generating a patch and send it as an attachment to the yahoo
group so everyone will have access to it.
We're always happy to see
videos/samples of stuff you've done with the framework (or Aibos in
general). We have a page of research groups
using Tekkotsu - we'd be happy to link to you and your publications!
You can also send encouragement to
Sony to renew our funding ;)
Also, check out our Yahoo group, tekkotsu_dev,
for news and communication.