I am away at the moment. If you want to take a look at what we have done so far do:
cp -R ~iam23/gatsby/aibo/gatsby_one somewhere_convenient
The Makefiles will work with the OPEN-R SDK in /usr/local or /nfs/data/aibo — add other locations in util/open-r-loc. Remember `make` builds everything but you need `make install` to gzip and copy things into the MS tree. Then (and only then) use ./upload to ftp onto a working and booted aibo.
Here are some randomly sorted notes:
- Sharing ideas, information and code
- Compiling Stuff
- Development Resources
- Development Notes
- Sony Memory sticks
- Wireless network
We'll have short meetings on most Friday afternoons.
There is aibo stuff in /nfs/data/aibo, please place new things of general interest in the incoming directory and I'll sort them out. Printouts of the OPEN-R sdk and a tutorial are in a ring-binder kicking around with the aibo.
I'll probably put my stuff in a CVS repository writable by the aibo group. If I do this it will also dump weekly tar-balls to this page, but we don't have anything worth showing yet.
OPEN-R, MIPS cross compilation tools and the Java2 SDK V1.4.2 have been set up in /nfs/data/aibo in Gatsby.
If you have a build tree which assumes the normal path for OPEN-R (eg OPEN-R samples or the Tekkotsu framework), you could fix all the Makefiles within the tree with this line of zsh/perl:
zsh -c 'perl -e "s#/usr/local/OPEN_R_SDK#/nfs/data/aibo/OPEN_R_SDK#g" -p -i **/Makefile'
Obviously this sort of dumb thing is dangerous so always have backups! The gatsby_one code I've written has a Makefile that checks a list of locations at buildtime so that this is not necessary.
If you want to compile or run the Tekkotsu mon stuff then you'll need a working Java2 install. You could put this in your shell's configuration:
The Tekkotsu_XXX/project/Makefile also needs sorting out — but we probably want to get this set up in CVS if we're going to use it, and then there'll be instructions on how to get that.
If you use this java setup in your browser, stop doing so as it has a security flaw.
- [OPEN-R SDK] official web site — browse around, there is a lot there.
- Tekkotsu Development Framework for AIBO Robots (built on Open-R)
- OPEN-R SDK Tutorial / Jean-Christophe Baillie — but look at all the stuff on the above two pages!
NB Sony's software is not written using freely available tools and it is not available in any source form. From a research point of view, therefore, it is useless and should be ignored.
this project looks fun. Different gaites of aibo walks implemented in simulation.
More gait generation here, this time on real aibos using GAs. 7m/min doesn't sound that fast though.
Yet more evolutionary gait generation fastest=9m/min, but more than just speed here.
This stuff is probably not very useful for us:
- AiboHack — a load of cute behaviours and possibly some useful information
- R-Code — higher level scripting for the Aibo
- Aibo webring
- aibosite.com — info not targeted at developers
- aibo-friends — discussion board, and some useful information.
- See the bottom of here for a very old robotic dog!
Random thoughts and notes. I'll try and structure them in a separate page when there's more to say.
I like the idea of code reuse and think we should more seriously investigate using the Tekkotsu framework. Or at least using some of its header files, to make any future integration easier. For the moment I've just been looking at doing very basic things with the plain OPEN-R API to get a better understanding of how things work without taking too much on board at once.
Do not put underscores in core class names.
I think it is best not to bother handling messages from the OVirtualRobotComm Effector subject. As in the ball tracking head demo we should just create a queue of commands to the effector when we are ready. The tutorial referenced above has an explanation for this based on performance. Also it's just a right pain having to deal with messages from the motor system. You kinda have to reply to every message if you want to keep getting them. But this isn't very natural. We decide what and when to do based on what we are trying to do in conjunction with sensor readings, not on the fact that the motor system happens to think now is a good time to get data. Coding is actually much easier if we don't bother having an entry point for Effector (De)Assert-Ready messages. We can ask the motor system if it is ready at any time if we want or need to.
The API assumes that we are only interested in the kinematics rather than dynamics of motor control. In other words, we cannot directly specify target forces/torques, but only target angles for each joint. The target angles are then fed to a closed-source PID controller, for which we must specify P, I and D "gains" and P, I and D "shifts". Sony recommend a particular set of values for each joint. I don't know what the "shifts" are or do, but Sony's values are the same for every joint. I've managed to make the legs unstable by tweaking P, I and D values, but I haven't managed to create any sort of nice springy behaviour (so far). In theory we could invert the PID controller so that we could effectively specify torques. I think this would be a lot of work and fairly pointless though.
I'm still not sure about some of the "avoid burning out the motors" issues. Aibo has turned itself off on me a few times though, so the operating system has some safety features built in.
- RoboCup Legged Robot League.
- CMU Coral group code downloads — probably much more generally useful than robocup.
A memory stick reader/writer is essential. It's needed to set up the wireless network and whenever we trash the network setup. It can sometimes be quicker too as if the Aibo is turned off you have to wait for it to boot up before you can use the OPEN-R ftp server.
Memory sticks use a FAT filesystem. While extensions to the original format allow you to use long filenames, do not do this. All of the OPEN-R samples have 8.3 format file names for a reason (not that this is documented anywhere I've looked).
Aibo memory sticks have annoying/evil copy protection. There are various warnings that non-Sony stick writers may trash this data rendering them useless with the Aibo. Our experience is you can ignore this advice (but at your own risk).
We have a "Viking IntelliFlash USB 6 in 1 Flash memory reader", which reads and writes all sorts of solid state memory and makes them available as a drive through the usual USB mass storage system. Setting up and finding the correct device to mount in linux was a bit fiddly. This advice was invaluable.
Sony options are: 1) use a Vaio laptop with a built-in reader (note that we corrupted a memory stick in one of these by pulling it out too early — however we could fix the filesystem without a format). 2) buy a USB reader (eg the MSAC-US1A).
This took an inexplicably long time to get working, here is an anonymised version of the configuration we used in the end:
HOSTNAME=AIBO ETHER_IP=192.168.xxx.yyy ETHER_NETMASK=255.255.255.0 IP_GATEWAY=192.168.xxx.zzz ESSID=the essid we use WEPENABLE=1 WEPKEY=????? APMODE=1 CHANNEL=X
You must have the wireless network set up before you turn the aibo on! Otherwise the Aibo just turns itself off immediately in a very unhelpful way.
You need to replace the yyy, xxx, zzz, ????? and X. If your ESSID has spaces you don't have to escape or quote them. We never got APMODE=2 to work, even though the docs claims this auto-detects the mode. WEPENABLE=1 — you do use encryption, don't you? The WEPKEY should be 5 characters long. If you have a 10 digit hex key then you need to convert it to ASCII with a hex editor or something. The channel number needs to match your network.