Whew! It's been a while since I last had a chance to post a new diary entry.

My new job demands a substantial amount of what had previously been my free time to work on robotics projects. But, that's life at a startup ;)

I haven't been able to put in much time working on the Blue Cube or Zaza in the last five months, but would very much like to get back to doing so.

I was able to spend a few hours at the Tech this weekend working on Zaza, but it appears her batteries are in need of replacement again, as the voltage never got much above 11.3V. It appears the maintenance technicians left the robot connected to the charger w/o having the the robot power on for a month or more. unfortunately the charger from RWI isn't smart enough to reduce the charge current proporionately, and managed to cook off a lot of the hydrogen in the gell cells. Oh well, there goes another $500...

I wrapped up installation and testing of a simple BASIC Stamp 2 watchdog board for Zaza's ACCESS.bus MSP network yesterday. The board has the ability to detect when the ACCESS.bus is hung, and and can assert the MSP reset line when directed to do so by the 'brain' CPU (zaza1). I have begun work on a new version of the MSP supervisor utility to take advantage of the enhanced functionality that the new board provides. When completed, the utility will allow fail-safe starts from power up, eliminating the need to press the ACCESS.bus reset switch, as well as detecting bus problems during normal operation. I had considered adding code to support bus monitoring to the baseServer, but this might break things, and make porting the codebase to CARMEN more difficult. Bus monitoring will be implimented via an external supervisor utility that links with libmsp. This will allow passive bus monitoring to occur regardless of whether baseServer is running.

The schematics (gEDA/gschem + additional custom symbols, PNG) and current firmware are here.

After several months of work I was finally able to migrate Zaza's main controller CPU (zaza1) to a more recent Linux distribution/kernel. This allowed upgrading to the lastest version of BeeSoft which should help improve reliability a bit. The OS upgrade will also let us start experimenting with CARMEN, and begin the process of porting the current codebase to this fully GPLed robotic navigation toolkit.

Oh dear, it appears Arthur T. Murray has found robots.net. If you have ever been curious who this guy really is, check out this FAQ assembled by Tristan Miller, I found it rather interesting.

I wrapped up work on a new version of Zaza's voice server this weekend using the POE framework and POE::Component::Festival. This version resolves some of the more troubling architectural issues with the previous single-threaded releases of the voiceServer. Cues are now processed asynchronously with proper FIFO buffering so rapidly submitted input cues are neither dropped nor mangled as had been a problem when the voiceServer machine was under heavy load (ie. running in tourguide mode). A number of museum visitors have asked about Zaza's voice/face system recently and expressed interest in using it for other applications. As a result, this version is the first to have actual documentation, not just source comments ;) As time permits, I'll do the same for the other voice system components. I also threw together a basic system diagram that documents how all the voice/face components fit together.

Hooboy... Lots of robotics related updates since the last diary entry:

Zaza
I managed to fix a logic bug in the Phase IV (tourguide) button handling code that hadn't been debouncing the buttons properly during tours. It was a problem because kids like to press the buttons on Zaza's acrylic hood (repeatedly), which caused a bunch of voice cues listing the intended exhibit destinations (or information on the current exhibit if the robot had arrived at an exhibit) to stack up, sounding a bit like a broken record :P

I also fixed a problem with the POE face client (interfaces remote Java face applets with the voice server) that would occasionally cause remote face applets to 'loose sync' and stop receiving new voice cues from the voiceServer.

During Phase IV testing over the last two weekends I noticed a problem with the voiceServer not rendering some voice cues that list the exhibit destinations during a tour. It looks like a race condition exists when there are more than one active (unvisited) goal that causes the cues to be sent to the voiceServer faster than it can handle them, causing the first of the cues to be dropped. This has compelled me to consider rewriting the voiceServer to use POE to manage the threading issues. I had a quick glance at David Huggins-Daines' POE::Component::Festival and it looks like it could be used in place of direct access to Festival::Client::Async for POE, but both the Perl module, and the 'synth-poe' example needed to be tweaked before they would work.

I stumbled across some new voices for Festival from CMU last week. The first (sample) uses 'cluster unit selection' which basically assembles a synthesized waveform from components of a database of pre-recorded, tagged speech. The results can very from fantastic to horrible, and takes far too long to render on existing hardware, eliminating the possibility of real-time synthesis. It's unlikely we will be using this one with Zaza. The second (sample) uses the same ARCTIC database, but is converted to diphones through HMM analysis. It has less inflection than the current voice (sample), but seems to be quite a bit more intelligible on Zaza's current audio hardware. Due to some differences in text analysis, using the slt_hts voice requires making some changes to both the face applet, and the voiceServer. I have already updated the face applet, and plan to do the same with the voiceServer this Friday.

Blue Cube
I threw together some Makefiles, and updated the READMEs for libnmc and picservo-test to make the build process a little easier.

I also started work on the CARMEN interface, but need to make some API decisions before progressing any further. I am planning to duplicate the critical interfaces used with the open-sourced version of the Nomadics Scout hardware interface library. This should make it easier to integrate with other robotics toolkits like Player/Stage.

After a great deal of waiting, Thomas Baier finally released a version of 3DWin that worked with a current version of Moray, allowing me to export my model of the Blue Cube that I made a few years ago to VRML. I also put up the hamaPatch model of one of the Blue Cube's 'quarter panels'. At some point I'll rebuild the model using this more accurate model with BlenderCAD.

I finally decided on i2c as the sensor bus, allowing relatively simple interfaces to sensor nodes like the SRF08. Since the Blue Cube's mainboard doesn't have a built-in i2c interface like the VIA EPIA M motherboards do, I needed to find another sufficiently fast means of interfacing with the i2c network. I had a look at dafyddwalters' OAP parallel port i2c interface, but the lack of proper isolation on the SCL line, and the nonlinearities of using transistors for switching concerned me. I found an old article by Simon G. Vogl that used a slightly better design and made a few modifications. The latest block diagram shows all of the current/planned systems on the robot.

I have an initial design for the power distribution board, but need to do some testing before building it. The circuit allows peripheral power to be controlled by the power management uC, as well as automatically switching to battery power when the external +24V dock supply is disconnected.