Very belatedly reported, Mikhail and I entered Savage Solder in the Robogames 2012 RoboMagellan competition, placing first. The goal was largely to see what we could do in a short period of time. With only about 2 months from start to finish, we put together a machine which handily took first place in the competition, despite having a few significant bugs and barely having been tuned for performance.

The strategy was relatively straightforward: Start with a capable platform, we used the HPI Savage Flux with a laptop, webcam, GPS, and IMU strapped on top. A Teensy USB was coded to read RC servo inputs, write servo outputs, talk to the IMU over I2C, and read the bump sensor while connecting to the laptop over USB. A simple Unscented Kalman Filter (UKF) kept a global world position using GPS in UTM coordinate space. The car followed trajectories using pure pursuit for steering and a PID controller around velocity. The trajectories were layed out ahead of time with a simple lua script that pointed them towards each of the cones in a series using Dubin’s curves. A separate target tracker maintained UKFs for one or more visible cones which were culled from a simple visual filter. Once a cone was certain enough, and in the right location, the trajectory tracker switched to making trajectories aiming at the cones and slowing down, until a forward facing bump sensor tripped. At that point, the car moved on to the next element in its sequence.

The biggest thing we didn’t even include in our design was obstacle detection or avoidance. With the u-blox GPS we used, we were able to achieve positioning performance that would usually constrain the car to within +- 1.5m of a desired path, which, together with careful manual planning, was mostly enough to keep it from running into things. This was helped by the fact that the landscape for current RoboMagellan events is relatively forgiving, having few dynamic obstacles which aren’t people.

The two biggest failings in the design were that 1) we ran out of time to tune the velocity and acceleration control to get the car to reach its speed performance. In the end, with the controller we had, we tuned the constants a bit to achieve a top speed around 5-7mph, but we were limited by how quickly the controller could slow down. The underlying platform is capable of 40mph+ with rapid (~4 m/s^2) acceleration. Second, was the mechanism behind homing on cones. The target tracking filter operated in the global coordinate system. However, while our u-blox was pretty good, it would often drift rapidly by several meters in one direction or another, which could confuse the filter and cause the car to miss the cone. Higher level logic caused it to retry, but every retry added a significant time penalty as changing directions is slow on the RC car platform.

In preparing for future competitions, we’re working on getting Savage Solder both so that it performs up to our original design, and also so that it can avoid some subset of dynamic obstacles, possibly just using a similar visual tracker so that it is capable of competing in events such as Sparkfun’s AVC.

Our spring vacation to Arches and Canyonlands National Parks.

One of the richest men in the world is going to build the biggest airplane ever.

And then he is going to use it to launch rockets.

From the NYT

I am announcing the first release of s3bdbk, a simple script to do incremental backups of block devices into the Amazon S3 storage cloud. For now, code is available just at github under an MIT license:

• https://github.com/jpieper/s3bdbk

And now for a little motivation:

In our virtualized environments at work, it is much more convenient to backup at the disk image level. In the event of a catastrophic failure where an offsite restore is required, I don’t really want to have to spend time installing a new OS image and getting it configured well enough to pull in the restored data. Our offsite backup needs are also relatively simple. Nearly all of our critical data is already consolidated onto one or two virtual images.

Existing solutions all seem to ignore the fact that disk images are so easy to work with in a virtualized environment. However, with an entire image, it just isn’t easy or practical to get it offsite with any existing tools:

• It is difficult to work with large images in S3:

  This has improved lately with multipart uploads, but many off the shelf tools you might want to use in an emergency won’t necessarily support the feature.

• Incremental backups of block devices is harder:

  With a filesystem, tools like rsync can with some ease narrow in on which subsets have changed without having to read the entire filesystem. Granted, with some extra patches, you can point rsync at a block device, but it only supports an identical block device as the remote target.

• Naive backup rotation is very expensive:

  Simple incremental backups work at the file level, that clearly is not sufficient for a block device. Something like rdiff-backup will store reverse binary diffs, but it is somewhat brittle, is hard to manage your older backups, and doesn’t work on block devices.

s3bdbk solves these problems by using a simple block format written to S3 (or a local directory). The block device is:

1. Chopped into chunks (32meg currently)
2. Each chunk is hashed to a checksum, and a canonical name is created that includes the backup name, the block number, and this hash
3. If the canonical block name already exists in S3, the chunk is done already, otherwise we upload it.
4. Once all chunks are uploaded or already present, we write a “manifest” to S3, which lists all the blocks in this version in order
5. As a nicety, we store a “current” file which points to the most recent manifest.
6. Finally, if a limit on the number of incremental backups is specified, a weighted random purge is run to remove older backups while maintaining probabilistic spacing.

FTDI once again updated their firmware, this time to 1.4.2. The release notes are promising. My goal for today is to try and validate as many of the fixes as I can. If enough of the regressions are fixed, the intended fix to USB host polling rates would actually make my device playable!

Update:

The 1.4.2 release did manage to fix the most glaring of bugs, most of the crashers and obvious incorrect behavior is now resolved: Issues Page. Even some of the bigger ones appeared to have progress made, specifically, the USB host polling rate problem. It did now appear that the host driver polled at 8ms for my device which requested a 10ms poll rate.

That was the upside. The downside was that for some reason the device only responded to every 3 out of 4 poll requests for data. (On my linux host, which also polls at 8ms, it responds to every single one). Additionally, something got broken about enumeration for devices which are connected at powerup that made enumeration moderately unreliable. That is a little bit ironic, given that I never had any problems with this before, and the release notes indicate that problems related to this were fixed in 1.4.2.

At this point, I’ve decided against freshening up my scope USB decoding skills again to see what the VNC2 library is doing wrong during enumeration or during the 1/4 interrupt IN polls that nothing comes in. Besides, rock band isn’t as popular as it was 8 months ago anyways. On to other projects, and maybe in a couple more years the VNC2 firmware will be usable enough to revisit.

Two items of note: First, FTDI released a service patch to version 1.4.0 which looks to contain many bugfixes. Second, they’ve finally gotten back to me about the specific issues I have been having trying to use the firmware in my project.

This release looks like it did fix one of the issues I had (#11), although it was only a regression from 1.2, so it wasn’t one of my original showstoppers.

FTDI also indicated that a number of the other problems are scheduled to be fixed in a 1.4.2 point release due out in mid-July. Fingers crossed.

I worked through all the issues I had uncovered, testing each with the 1.4.0 version of FTDI’s toolchain and firmware. I can’t say a single one was actually fixed. The results by the numbers:

• Fixed: 0
• Still Broken: 6
• Feature Partially Removed: 1
• New: 4

Hopefully the next firmware update will actually fix enough that I can make progress again.

I was hopeful today when I discovered that FTDI had released a new version of their toolchain and firmware for the VNC2. As mentioned previously, I have been having a large number of problems with my rhythm controller adapter application, due largely to bugs and lack of features in the 1.2.2-SP1 version that had been current until today.

…

My hope lasted only a very short time.

…

The immediate problem I had been working on was with link-time optimizations producing bogus output. In 1.4.0, the GUI option to select link time optimization was removed, but the command line tool still supported it and produced corrupted output. Half points.

Then, as soon as I tried to reproduce the most critical of my issues I started having real fun. First, the compiler just segfaulted trying to compile my source. Then, once I had narrowed down the code which caused it to crash I fired up a new project so as to create the minimal reproduction recipe. However, the fresh project didn’t compile due to a trivial symbol mismatch in some FTDI generated code. Finally, after fixing that, I went to rename my reproduction recipe for transmission, and discovered that 1.4.0 started encoding absolute file paths into the .vproj files so that you can’t easily move or rename projects any more.

Ick!

Eventually, I will get around to testing all of my existing issues with the new toolchain, although it may take a bit as many of the FTDI provided examples have been re-worked to rely on the more advanced evaluation boards like the Vinculo, not my V2DIP2. At least that is my current theory, we’ll see as I dig in more.

The rhythm game adapter work has basically been stalled for the last two weeks waiting on the microprocessor vendor, FTDI, to try and come up with any type of resolution for the problems I’ve found in their firmware. While they have been gracious to respond at all, until now the responses have been less than useful. If I had an alternate platform with the same properties that had open firmware, or at least a source license, I would switch to it in a heartbeat at this point.

First things first, I am using the VNC2 from FTDI for this project largely because it is the only part I have found that has both a USB slave and an independent USB host controller on the same chip. Plenty of microcontrollers have a USB OTG controller, but that only lets you use one modality at a time. For the USB HID proxying to work, you need to have both simultaneously. One alternative would be to use a micro with a built in USB controller, then an external serial interface controller to handle the other end. Or you could just use two USB enabled microcontrollers, like an AVR, back to back. My goal on this project was to keep the part cost below $10, so that it could be produced in large quantities. Unfortunately AVRs with enough memory to hold a reasonable USB host stack are much more expensive even in quantity than the VNC2, much less the fact that you would need two of them. As far as external USB controllers, you can’t seem to find any low/full speed external controllers that are any cheaper than an entire microcontroller

In the hope that someone has had similar problems and knows how to work around them, I am going to start cataloging all the problems I’ve had with the FTDI toolchain and firmware here on my website. If nothing else, that will give me a clear record of what they may have fixed in subsequent versions.

One thing I am considering, although hesitantly, is reverse engineering enough of the register level interface to the peripherals on the chip to fix the problems myself. As part of debugging some of these other issues, I’ve been hand assembling bits of code to patch interrupt vectors and their code. However, looking through binutils, it isn’t hard to guess that bringing up a brand new architecture with 0 documentation is likely to take several man months of effort, which is a rather large yak to shave for such a small project.

The address bar in Firefox is named the “Awesome Bar”, and for a good reason. Aside from some occasional stuttering, it does an amazing job putting what I want most just at the top. Unfortunately, Firefox has so many other problems that I’ve abandoned it in favor of Google Chrome.

The one thing that I miss the most is the Awesome Bar. There are probably 10 pages that I revisit every day over and over again. In Firefox, I just typed in a word from their title, and up would come the link. In Chrome, I’m lucky if the link even appears in the list of available options. Usually I have to move down to the final “see all pages in history”, for which my desired page is almost always the top link.

Did Mozilla patent their frecency algorithm or am I just missing Chrome’s special brand of awesome-ness?