Now it’s up to the Deans’ Conference. I’ve turned in a rather large pile of forms, recommendations, letters, and transcripts. They’ll meet on Thursday and I should know if I’m readmitted by Friday.
Wish me luck!

More and more people seem to be fawning over Bush’s ridiculous “vision.” It’s not a vision, it’s political strategery. It is nothing but a waste of money, and the negative impact is already being felt, as evidenced by the recent announcement to abandon Hubble. (I only reference one article referring to the announcement).

I just recently came across this message in the Finder when I tried to rename a running application:

Are you sure you want to change the name of <appname> while it is open?

Changing the name of an application while it's open may cause problems with the application.

This is caused by the same problem experienced in ScreenSaver: if you change the name of, or move, the folder of pictures to which ScreenSaver is pointing, it will lose track of it.
Both of these problems happen because Mac OS X dicourages the use of Aliases, system-standard data structures for referring to file system objects. Instead, applications are encouraged to use path names. The problem with a path name is that it’s fragile: if you move the item or change its name or the name of any of it’s enclosing directories, an extant path no longer points to that item.

Because Mac OS X encourages the use of pathnames in applications as references to files (via CFURLRef, among other mechanisms), applications are very likely to store these paths, despite the occasional feeble warning against doing so.
Now, it’s one thing for an individual application to make this mistake, but for Apple to endorse this behavior by warning users that they shouldn’t change the name of running applications, rather than letting those applications break. Instead of forcing applications to do the right thing (store file system item references with Aliases, not paths), they make the user wrong by preventing (or at least discouraging) him from changing the name of a file.
Related to this is OS X’s emphasis of filename extension as the way to identify a file’s type. The filename is for use by the user, and the OS’s use of it should not impose any restrictions on what the file name can be.
In the case of filename extensions, Apple has gone to great lengths to try to hide the extension from the user. They still use a string of bytes to store an ID representing the file type, but what they’ve done is move the storage of those bytes on disk from a tidy, dedicated location to the end of the filename, where it gets in the way of the user. Though the hide it, it’s easy to get into situations where the user is either warned about changing the file extension (exposing it), or they inadvertently change the represented file type (without changing the underlying bytes). Bad, bad move, Apple.
It’s just another indication of how Apple has lost sight of what it takes to make a great OS: the details (to get really nit-picky, notice that the error message uses a single straight quote, instead of an apostrophe. It&rquo;s possible it just looks straight given the rendering). Ever since NeXT engineers crowded out Apple engineers, this has been the case.

Yesterday I added training wheels to the bot and allowed it to run free in the kitchen. The “training wheel” is a simple furniture caster attached to a 1.5" wide piece of aluminum bent in two places and bolted to the frame. The controller is running a very simple navigation program. It basically goes forward for two seconds, turns right for one, repeat. The timing is too far off to make any kind of recognizable shape, but it was a chance to see the ’bot in action.

There’s also a short high-power burst forward and backward (and forward again) to qualitatively determine what kind of torque characteristics the system exhibits. Interestingly, it’s enough to kick the caster wheel up off the ground, despite having two battery packs strapped to it.
For its first untethered tests, I added two 6-cell, 3000 mAh NiMH battery packs (the kind used in electric R/C race cars and planes) wired in series to give a nominal battery voltage of 14 V. This makes for rather large drop across the controller’s main regulator (and might even be outside the spec; I’ll have to take a look). Perhaps I should tap off of one of the batteries for powering the electronics.

What a crummy day. I spent so much time fiddling with the LCD code that I broke. I had started writing a basic PD speed controller. I was writing a fair amount of info to the LCD during the PD loop interrupt, which was taking quite large portion of the available executiong time, so I tried to tighten up the LCD code (more details in a later post). Well, I broke it. Many, many hours later, and after fixing it and having it all of a sudden stop working multiple times, I got it and the PD code working.
Now, I based this off an old article written by David Anderson. It does something interesting. If you command a speed of zero, and then turn a wheel by hand, it will resist that effort like a spring. If you then release the wheel, it will rotate back to its approximate starting point.
The calculation of the PWM signal is cumulative, even if there is an error of zero, so the PWM is being integrated (I think). I need to brush up on my understanding of PID controllers to figure this one out.