Older blog entries for rudybrian (starting at number 43)

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:

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.

I started work on Zaza's web-based map and start position selector yesterday, er... make that two days ago ;) The basic idea is that when a user selects Phase IV mode from the control CGI, a list of possible maps to run on pops up on the left-hand side of the control interface where the process monitors usually are. Selecting one brings up a list of possible start positions/headings for the specified map with thumbnails and descriptions of each. Selecting one of these passes the parameters to poslib, and the startup sequence begins. Meanwhile, the left-hand frameset returns to the process monitor CGIs. This should be simply enought for the average operator to handle. A really old screenshot of the control interface is here (Jeesh, I need to update that...)

To simplify building all of the support files for new maps, I am trying to use as many generic files and templates as possible. The localize.ini, and the map applet plugin HTML will be the same for all maps. The only down side to the latter is that a client browser might cache the map image from a previous run. I may work around this by modifying the map applet to query for the map when it initializes, but this will also require modifications to poslib, and the posServer CGI. There are a lot of options for generating the start position thumbnails in Perl, but the two I am currently considering are GD and PerlMagick. The latter looks to be the favored option, but some experimentation is required. This may also present a possible option for clients too old/slow to handle the map applet...

On another note, I pulled the Blue Cube out of mothballs this weekend. It's been a couple years since I did any real work on the Cube, and I was feeling rather guilty for letting it sit idle for this long. I decided to make a stand for the rear legs that would let me test the locomotion system software as needed without pulling the wheels off. There simply isn't enough room to grab the Cube if it goes AWOL in the lab. Since I last played with the motor software, I discovered some code written by Alan Killian for the PIC-SERVO for an article in Circuit Cellar. This should be pretty handy as my original code worked, but not very well.

After pulling off two of the quarter panels everything on the inside looked fine, save a few cobwebs. I put a voltmeter across the batteries and was dissapointed to see only a reading of 1.8V. It doesn't look good, but I plan to leave it on the charger a full 24 hours before making a diagnosis...

I was able to finish the cable harness repair job on Zaza Saturday 8/2. It took a few more hours than expected, but gave me the opportunity to clean up a bunch of the other wire management without fear of missing the following weekend's scheduled demo.

The demo on the 9th went as planned, but due to time restrictions we weren't able to do the regularly scheduled Phase IV test. Last weekend we were able to do both the demo, and the Phase IV test and things went quite well. Prior to starting the test, I was able to upgrade the JRE from Sun's 1.4.1, to the recently released 1.4.2 on Zaza2. Improvements in the networking, Java2D and audio code showed noticable reliability and performance increases with the face applet. The map and webcam applets running through the control interface on a remote Redhat 9 laptop also worked quite a bit better. Since ALSA is now supported, it is now possible to run a Sphinx audio capture client onboard to robot at the same time as the face applet.

Since migrating from the original Breezecom 802.11 (FH) WLAN hardware to Wi-Fi, there has been a noticable improvement in the performance of the localizer/planner during Phase IV tests. I attribute this to fewer lost laser scans being sent to the localizer due to bandwith saturation. Zaza no longer inexplicably 'gets lost', or 'gives up' searching for a route to the next target after being blocked by visitors for an extended period of time.

Things with work have settled down a bit, so I was able to spend yesterday working on a few of the outstanding issues with the Phase IV code. After adding the button management and destination announcement code a while back, we noticed a need to better integrate these two. I made some modifications to poslib, and poslibtcx adding some handshaking allowing the robot to announce the list of planned destinations when the robot begins moving, as well as when a user presses a button when the robot is in motion. After stopping at a target destination, the button management behavior changes and will eventually be used to speak additional information about the exhibit the robot is nearest to.

Since the basic operation of the tourguide code is now stable, it is now time to start improving the web-based control interface to allow dynamic map and start position selection to allow the robot to operate in this mode in other areas of the museum without substantial manual tweaking.

Things have been rather busy with work over the last few months so I haven't had much time to work on Zaza. To compound the issue, the robot's +5V booster DC-DC converter died on the 28th of last month and nearly vaporized some of the cable harness connectors that weren't rated for the load when running off of only one converter. Fortunately, a local surplus shop had a drop-in replacement for the booster module for really cheap. I was able to get some of the repair work done yesterday, but will need to spend some time on an upcoming weekend to wrap things up.

34 older entries...

Share this page