Recent blog entries for rudybrian

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.

I finally got around to porting JR Kerr's NMC library (supports the PIC-SERVO, PIC-IO and PIC-STEP) to Linux for use on the Blue Cube. A few years ago I hacked together a driver based on some example code, but the performance was sub-optimal and it was littered with bugs. I was inspired after running across Alan Kilian's code from his Circuit Cellar article, and decided to just rewrite the whole thing. As far as compiling is concerned, it's still a bit of a mess, but if you are interested you can get it here. At some point I'll throw together some GNU Autotools scripts, but it's usable as-is. Now that I have a working motion controll system, it's time to start writing an interface for CARMEN.

The good, the bad and the ugly...

First the good: I finally got Robbie Stone's updated CATC Access Bus card Linux kernel driver working on Redhat 6.2. This means that it's finally possible to upgrade the OS on Zaza's 'brain' CPU. This will allow the use of a smaller/more efficient motherboard, and begin experimenting and porting the current codebase to CARMEN.

The bad: As of January 2004 iRobot/RWI is discontinuing research robot sales, and will only be continuing support through the end of the year. This will pose a support problem for ongoing use of the robot...

The ugly: I finally got around to fixing one of the beeSoft conversion utilities that converts images into maps. Using beeSoft's map editor is painful to say the least, so having the ability to re-import a map image to a map allows use an image manipulation program to add virtual obstacles to a map much more easily.

I got some bad news this morning regarding ASIMO's planned visit to the Tech Museum at the end of January. Due to some poor planning and coordination on the part of both the Tech and Honda, the visit has been canceled. Honda is looking for alternate venues in Northern California but hasn't managed to secure one yet. Bummer...

I got some good news from the Tech Museum's Public Programs folks last week. They are planning to do a bunch of robotics-related activities in January leading up to ASIMO's visit at the end of the month. Since Zaza's Phase IV (tourguide) functionality is stable, we are planning to run tours on the last three weekends in January. We still need to work out the scheduling and facilitation details so nothing has been posted on the website yet.

From a development standpoint, I am freezing the feature set until after January and concentrating on performance and resource utilization improvements for the client interface. Since many web visitors won't have the necessary JRE installed to run the applets prior to the tour, I'll be writing a 'browser prequalification' applet with the requesite Java plugin Javascript/HTML to auto-download the JRE for the Windows platform, or link to the appropriate site for other platforms.

Since my last post I made a few updates to the map applet and posServer CGI to support auto startup/shutdown of the client applet. Last weekends test revealed a bug that occasionally causes the shared memory segment, used for signalling the showmap CGI to return the Java plugin HTML, not to be updated after poslibtcx starts up. My current theory on the cause is that the posServer CGI updates the segment too early, it immediately gets flushed by poslib::poslibinit() during the startup sequence of poslibtcx. I also finally remembered to take screen shots of the current versions of both the control and user interface screens.

Last Friday I finished off work on the first working version of Zaza's selectmap CGI. I ended up using the Perl interface to ImageMagick for auto-generation of the start position thumbnails, but the performance is sub-optimal. The antialiasing functions perform poorly. The image-shearing-based rotation algorithm doesn't work well on small images, so the robot image looks pretty bad (See here, here, and here). To top it all off, it chews up 100% of the server's CPU for three seconds while generating images. Yuck...

I also successfully tested auto-generation of the map.initprobs and map.laserDist.1.1000 files (the map.planmap file could also be auto-generated, but would need to be edited to include unseen obstacles for the obstacleServer.) This simplifies some of the aspects of running with new maps. The first two files are used by the localizer system to determine the robot's initial pose on startup, and to pre-load the Bayesian position estimation routines of the localizer for faster position estimation than interpreting a BeeSoft-format map in real-time would allow. Carmen's new mapping system/localizer are all integrated, so all the data included in these files are included in a single map. I look forward to the simplicity this allows ;)

For some reason Redhat included some changes in the last eratta version of mod_perl for Apache 1.3.27 that reduced the scope of subroutine references and broke external references to poslib functions in the posServer CGI and C-language wrapper for poslib used by poslibtcx. To work around this poslib needed to be defined as a package, and all functions updated to explicitly reference the package functions. I guess this is the proper way to do it, but I had to waste a few hours resolving the problem instead of finishing off the applet/Java plugin auto-generation CGI.

I made a few additions to poslib, and started work on another CGI (showmap) to add support for auto-content generation for the map applet frame. When finished, it will automatically cut-over to the map applet after selectmap starts up all of the Phase IV components, or a status page with the time of the next scheduled run. I'll also need to update posServer to provide functionality for status polling with the ZazaMap applet.

On another front, the Blue Cube's batteries are badly sulfated and have been on the charger in float mode for two weeks with all showing signs of improvement, but only three of the five returning to a reasonable voltage in the last few days. Gotta be patient I guess ;) Last week I added a simple 250ms RC delay to the 'power good' line of the motherboard's power supply which should help improve startup reliability.