When you access the new repositories, you will get:

svn: Could not open the requested SVN filesystem

And when you look in /var/log/apache/error_log, you will see:

[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] (20014)Internal error: SQLite compiled for 3.6.11, but running with 3.3.7
[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] Could not fetch resource information.  [500, #0]
[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] Could not open the requested SVN filesystem  [500, #200030]
[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] Could not open the requested SVN filesystem  [500, #200030]

Problem:

What is happening here is that the libphp5.so loaded by Apache loads its own out-of-date implementation of libsqlite. Then mod_dav_svn.so calls the sqlite functions from php instead of the libsqlite.so it was build against, and that the svn excutables on the machine are using. The real problem here is that if the repository uses a newer SQLite version, it might be unreadable when accessed by the older version.

Several people have suggested recompiling version things to fix this, either by removing one of the sqlite libraries, or linking both to the same version:

• [feedface]
• [subversion-users]
• [org.tigris.subversion.users]

Solution:

However, there is a much simpler solution that can work — for the same reason that the older repositories work. Mod_dav_svn doesn’t seem to actually care if it’s linked against the wrong library unless the DB it is accessing uses some feature it doesn’t have access to. So if you create your new repository with a little backwards compatibility, the older SQLite can access it just fine and everyone is happy. Thus, I did the following when creating my new repo:

# svnadmin create --pre-1.6-compatible /path/to/repos

This seemed to solve the problem just fine.

Alternative Solution:

topop99 suggested another solution, which is to reorder the php5 and dav_svn modules are loaded by apache2. This presumably allows dav_svn to use the correct libsqlite before php5 comes in and ruins everything. Thus, open up httpd.conf and order the two as such:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule php5_module modules/libphp5.so

I haven’t tried this myself, but it might be useful to someone else out there. Thanks topop99!

Materials:

• 1 – Plano line spool box
• 1 – 1.5″ thick piece of very-soft polyurethane foam (the soft skinless foam used for packaging)
• 4 – 100′ spools of UL1213 26AWG stranded wire (but you can use anything that comes on 1.5″ wide spools)

Instructions:

1. Cut a 6.25″ x 2″ piece of the foam.  This will be used to hold the spools in place.
2. Open the line spool box and put your four spools on the bottom row.
3. Take your foam piece and wedge it into the top half of the line spool box, as close to the hinge as possible.  It should fit snugly.
4. Take the wire from each of the spools and thread it through the grommets on the top half of the box.  The result should look like the following: 
5. Carefully close the box, and the foam should lightly push against your spools, holding them in place.  That’s it, you have a lightweight, neat little wire caddy to take with you.  

Tips:

• You can play with the thickness of the foam to vary the tension
• If one of your spools is really sticky, make sure it is seated correctly, and not riding on one of the ridges along the bottom of the box.

Steps

1. Sign up for Amazon Web Services.  There are lots of tutorials on how to do this, it’s pretty easy.
2. Run the machine instance for a version of Ubuntu.  Canonical makes and packages these.
3. sudo apt-get upgrade
4. Follow instructions on ROS web site for building and installing ROS.
5. Do whatever secondary installation you want on the new node
6. TODO: Repackage the instance as a nice clean AMI.

That’s all I have so far, let’s see how this goes!

UPDATE: 2010-03-19

So ROS released their box-turtle release, which provides a package repository for more recent version of Ubuntu! This means that making an AMI with ROS is as simple as using the stock Ubuntu AMI, then adding the ROS repository and adding the box-turtle base packages.

Things you need:

• BeagleBoard (Mine is a Rev B7)
• Uboot-mkimage (Ubuntu has this as a package)
• An SD card reader on a machine with ext2/3 support

Step 1: Formatting your card

Because the BeagleBoard firmware (u-boot) can only easily read FAT32, and Ubuntu is much happier with EXT2/3, the first step is to make two partitions on your SD card.  I was able to do this using the Disk Utility on my Mac, after installing fuse-ext2, but any partition manager should be able to do this.  You want the following setup:

• Partition 1: 50MB – FAT32
• Partition 2: The rest – EXT2/3

The exact setup isn’t that important, the main thing is that the FAT partition is first and large enough to hold the boot kernel.

Step 2: Upgrading the firmware

Since I have no idea what crazy firmware my BeagleBoard came with, the next thing to do was upgrade my board to some known, reasonable version.  You will use the FAT partition on your newly formatted SD card for this purpose:

Go to the BeagleBoard downloads page and get the latest versions of the following files:

• x-load.bin.ift
• MLO
• u-boot-flash.bin (sometimes named u-boot-f)
• uImage.bin

(When you download these, these files will have version information stuck on them, like “x-load_revc_v3.bin.ift”.  You should rename them to look exactly like the file names above.  This is so that in the next step, the commands we use will have the correct filenames.)

Copy the files to the SD card:

All of the above files should be copied to the root of the FAT partition of your SD card.  There shouldn’t be anything in that partition other than these 4 files, named exactly as above.

Upgrade the firmware:

Connect to the BeagleBoard over the serial interface, so you can use the console.  The Beagleboard serial interface is 115200 baud, 8N1.  I like to connect using GNU Screen, so I do the following:

screen -U /dev/ttyUSB0 115200

Now, plug the SD card into the BeagleBoard, and let it start up the boot process.  When you see it get to the prompt about autoboot, press a key to interrupt it:

Texas Instruments X-Loader 1.41
Starting OS Bootloader...

U-Boot 1.3.3 (Jul  8 2008 - 16:29:02)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle Board + LPDDR/NAND
DRAM:  128 MB
NAND:  256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
Audio Tone on Speakers  ... complete
Hit any key to stop autoboot:  0
OMAP3 beagleboard.org #

Now, at this point, you have all the things you need to follow the BeagleBoard NAND flashing instructions.  There are several versions, but I found the Google code version to be the best for x-loader and u-boot, and the e-linux.org wiki version better for the kernel image (uImage). You will do 3 write sequences, one for x-loader, one for u-boot, and one for uImage.

Step 3: Putting Ubuntu on the SD card

The details of making a custom Ubuntu image can be found on the e-linux.org wiki.  However, I just used the demo images linked on the wiki, as I didn’t really need a custom image with a ton of stuff.  So first, I downloaded an unzipped the tarball of the Karmic (9.10) demo image.  It uses 7Z compression, so you might need to install 7zip if you don’t have it.  Included in the tarball are two files, a vmlinuz-* file that will be the kernel image, and a large armel-rootfs-*.tar that will be the root file system.

The installation details are hidden on the wiki, but I will reiterate them for clarity:

• Install the ubuntu package uboot-mkimage.

  sudo apt-get install uboot-mkimage

• Use the vmlinuz-* file to make a uImage file.

  mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d ./vmlinuz-* ./uImage

• Create a boot script file called ubuntu.cmd with the following lines (note: if you use ext2, change the reference in the second line of this script from ext3 to ext2):

  setenv bootcmd 'mmcinit; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000'
  setenv bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro vram=12M omapfb.mode=dvi:1280x720MR-16@60'
  boot

• Compile the ubuntu.cmd script into an ubuntu.scr file.

  mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Ubuntu 9.10" -d ./ubuntu.cmd ./ubuntu.scr

• You should  now have two files, uImage and ubuntu.scr. Clear off everything else in the FAT partition of your SD card and copy both of these files there, and rename ubuntu.scr to boot.scr. Your FAT partition should just contain two files: uImage and boot.scr.
• Finally, copy the root filesystem to your EXT partition.  You can do this directly from the tar archive:

  sudo tar xfp armel-rootfs-[fill this in].tgz -C [SD card EXT mount]

Lastly, there are a couple of quick hacks that need to be done for Karmic (9.10) to work. The e-linux guide is pretty clear about this part, so I’ll just post the relevant link to their wiki section.  Basically, you just need to edit a couple of config files on your EXT partition so that the kernel mounts it correctly and doesn’t freak out. Be careful with the paths though, if you forget the ./, you could easily end up editing your own machine’s config files instead!

Now finally, at this point, you can plug the SD card into the BeagleBoard, and you should get to a login prompt.  Awesome!

Now, aptitude auto-remove almost solves this problem, but there are still cases where for one reason or another, auto-remove is fudged up or something, or you just want to uninstall a few packages.

For these situations, I offer the following simple, terminal-based hack solution:

1. Open Synaptic package manager, go to File>History, and browse around until you find the packages you want.
2. Select the packages and copy them (or just select them and use the magic middle click buffer)
3. Open up a text file, say foobar.log, and paste the list of packages into this file
4. Run the following command in a terminal:

sudo aptitude remove `cat foobar.log | awk '{gsub(/\(.*\)/,"");print}' | xargs echo`

This will tell aptitude to remove all of the entries that you pasted into foobar.log.  Awesome!

What’s a roboticist to do?  Well, obviously, create a software hack that forces the gumstix to reassociate when its signal strength to the current AP gets low!

At first, this seemed to be a little tricky, as it is kind of a pain to deal with the parsing minutia necessary to figure out which access point is the best.  Luckily, Gumstix/OpenEmbedded has a solution, in the form of wpa_supplicant.  This little daemon is designed to allow connections to WPA-enabled networks, which is not useful, except for a nifty little hidden feature: it automatically re-associates with the best AP if the hardware “happens” to do a scan.  Well, we can force that using iwlist wlan0 scan!

So, the solution is twofold:

1. Write a background script that measures RSSI and runs iwlist when signal gets weak.
2. Configure wlan0 to use wpa_supplicant on the Verdex.

The first part isn’t too bad.  We need to write a script that loops, checking the RSSI of the current AP, and starts scanning only when the RSSI gets low.  Using copious amounts of text hackery, I wrote the following script to do exactly that:

#!/bin/sh

echo STARTING SCAN-O-MATIC
while [ 1 ]
do
	RSSI=`iwconfig wlan0 | grep Signal | awk '{print $4}' | cut -d ":" -f 2`
	if [  ${RSSI} -lt "-60" ]
	then
		iwlist wlan0 scan > /dev/null
		sleep 5
	else
		sleep 2
	fi
done

For convenience later on, I saved this script as /etc/wpa_supplicant/scan.sh.  With that done, the next step isn’t too tricky either.  wpa_supplicant ships with the gumstix-basic-image, so as long as you are using that, you probably already have wpa_supplicant.  To get it to run with wireless (wlan0), you just have to change a couple of config settings.  Create the file /etc/wpa_supplicant.conf.  This file will contain the configurations for the networks you want wpa_supplicant to try to join.  Since I only have one network, mine looks like this:

ap_scan=1
fast_reauth=1
network={
	ssid="FOOBAR"
	key_mgmt=NONE
}

If you have weirder settings, just look up the docs for wpa_supplicant. Note the ap_scan=1. I think that is important for ensuring that wpa_supplicant will reassociate networks when you scan. Next, we just have to tell the Gumstix that we want to use this stuff when we activate wlan0. So, we put the following into /etc/network/interfaces:

auto wlan0
iface wlan0 inet dhcp
      pre-up wpa_supplicant -Dmarvell -iwlan0 -c/etc/wpa_supplicant.conf -Bw
      up /etc/wpa_supplicant/scan.sh &
      down ps | grep scan.sh | grep -v grep | xargs kill `awk '{print $1}'`
      down killall wpa_supplicant

This should look very similar to the WPA example that gumstix provides. However, you can see that we also start our scanning script in the background, and kill it when the interface goes down. Make sure you comment out any other iface block for wlan0, as having multiple definitions will screw things up.

Now, just reup the interface and voila, wpa_supplicant will come up and associate to the best access point. If the RSSI drops below our threshold (-60dB in the above), then our scan script will run, and wpa_supplicant will use the results to associate to a better access point. It seems to work fine for running around pretty dense wireless network areas, with about a 3 second delay every time it actually tries to switch networks. So have fun and let your robots run free!

The two key things to know are that qmake really wants to use gcc for linking, and that hidden in the options.pro file are the cpu architecture flags.  That just means the following options are needed:

QMAKE_CXXFLAGS = -march=armv5te -mtune=xscale
LIBS += -lstdc++ -lm

Then, it’s a matter of convincing qmake to use the existing qt3-embedded mkspec file.  This was a bit tricky, and I’m still not sure I did it right.  My solution was to throw a couple of exports into the recipe:

export ARTKP=${S}
export QMAKE="${STAGING_BINDIR_NATIVE}/qmake"

Then, voila, we have a recipe that yields an ipk that installs ARToolkit Plus into /usr/lib on our gumstix!  If anyone wants it, feel free to grab the tarball and stick it in user.collections/packages.

Tarball of recipe: artkplus.tar.gz

IPK binary package: libartoolkitplus2_2.1.1-r0_armv5te.ipk