--Finished first draft of run-imu and associated changes to emperor, as well as a script (run-emperor) to start and stop them together.  The programs seem to work fine together. IMU logging, set to 50 Hz in run-imu, has sped up, but not all the way to 50 Hz.  Based on timestamps in the log file, the average update is at about 37.2 Hz, with a standard deviation of about 11.5 Hz.  I think this might be caused by the fact that the code is written for the Gumstix to poll the IMU for data every time the SIGALRM timer (set to 50 Hz) goes off.  Could it be as easy as setting the timer for a higher rate?  Or would it be better to change the code so that the IMU is constantly outputting data as fast as it can, and the run-imu is constantly listening?  Or maybe its the inaccuracy of timestamping based off the Gumstix clock (i.e., when the data finishes transferring)--maybe use the millis() function on the IMU to measure time between data points.
--Tried setting timer rate above 50 Hz and got bad results.  At both 60 and 55 Hz, observed intermittent slowdowns in frame rate (5-6 fps/camera in some seconds, with normal 11-12 fps/camera in others) as well as bogus data in the IMU log file (extra newlines, and lines that were cut off or missing the first part of the line).  Don't think this will work.  Next going to try adding a timestamp from the IMU.
--After much experimentation and frustration, got the IMU timestamp passed to the Gumstix and on to seykhl.  Started by trying to use the method that the readings from the IMU use, but I couldn't get that to work.  The IMU data are floats, which get read into their array using type-punning to char*.  However, the timestamp is an unsigned long int (32-bit), and I couldn't figure out how to get a correct value out of type-punning that.  I ended up breaking up the 32-bit int into 4 8-bit ints on the IMU (using bit shifting/masking) and sending each individually, then reconstructing the int on the Gumstix after receipt.  IMU log now has IMU timestamp as well as original Gumstix timestamp (and I discovered upon analysis of my data that the interval between the two timers is indeed fixed).
--Unfortunately, the extra computations on the IMU needed to break up the timestamp int seems to have slowed the IMU down--now I'm only getting updates at about 25 Hz, although the data is arriving at a much more consistent rate--the standard deviation dropped almost an order of magnitude to 1.5 Hz.  This actually might be helpful, since a consistent interval simplifies integration.  I'll spend a bit of time tomorrow seeing if I can find a faster way to send the IMU timestamp, and then I'll work on changing the IMU/Gumstix setup so that instead of the Gumstix polling the IMU at an interval, the Gumstix will merely listen while the IMU sends data as fast as it can.