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.

There are a couple items of note since the last diary entry, so heck, why not write another one :)

We finally got the bridge hardware necessary to port Zaza over to the Tech's 'new' 802.11b wireless network two weeks ago. The extra 8Mbps noticably improves the response time of the face applet, and the framerate of the webcam. The museum's IT folks finished upgrading the firmware on all of the AP's last Friday, and resolved a cabling issue causing problems with an AP in the Exploration gallery on Monday. By Friday it should be possible to wander the robot through the whole museum again (Huzzah!)

I spent some time over the last month re-writing the map applet, so that it would be easier to make UI changes using Netbeans' Form Editor. The earliest versions of the applet had been hand written, then were eventually imported into Netbeans. Since the import tool has no facility for auto-generating forms UI changes were a bit more involved. I was also able to fix a few more bugs in this release. Getting position updates now happens as a background thread independant of the Swing GUI, so there is a noticable performance increase. I also fixed a bug that prevented the scroll bars around a map from working properly in auto-tracking mode.

A bunch of new pictures have been added to Zaza's Hardware page that Robbie, one of the project volunteers took last year during the major repair of Zaza's base in September. If you have never seen inside of a synchro-drive system have a look, it's quite interesting.

It's been a while, so I guess it's time for an update ;)

Back in November I fixed a bunch of bugs and added some substantial features to Zaza's voiceServer. The module now has full support for Sable markup on input voice cues. This allowed reintroduction of the sound effects we used with the old VB version of Zaza's face.

I finally managed to squash a longstanding bug a few weeks ago in Zaza's tourguide code that would occasionally cause the robot to not notice that it had arrived at an exhibit destination. It's not an elegant solution, but works consistantly.

Last week I added initial back-end support to the poslib module for button interactivity during a tour. This will (eventually) allow visitors to press Zaza's three buttons when she is stopped at an exhibit to hear additional information about it (beyond the standard monolog), language selection, etc... It also announces the destinations the robot plans to visit when a button is pressed when in motion.

We have managed to max-out our offboard server during the Phase IV test runs. During previous tests the robot would inexplicably get lost from time to time. We had attributed this to a network or hardware glitch, but it appears that the machine would get I/O bound when running the web-based GUI locally and cause the localizer to miss critical updates from the base and laser servers. Running the web interface on an external laptop seems to improve reliability. Ideally we would have dedicated machines for the web interface, video server, and localizer/planner but a single-processor PIII 800 is all we have available at the moment.

Zaza is back in action!

The encoder adapter cable arrived from iRobot on 10/17 allowing the installation of the last replacement motor on 10/18. Everything with the new motors and belts checked out during tests in the afternoon.

The following week the Museum's shop was able to mill some cooling/speaker grille slots in the upper-enclosure panels. They did a fantastic job, and the slots do everything we had hoped they would. The internal temperature never gets above 94 degrees even under high-load, and the audio fidelity of the synthesized speech is much better.

Robbie Stone, one of the other Zaza project volunteers discovered what Sebastian has been up to in the past year or so. After the talk he gave at PARC in September of last year he hinted that an updated and open-sourced (yea!) version of BeeSoft was in the works. The CARMEN toolkit is fruit of their labor and looks like it could be a very good thing. Included in the standard distribution is a Monte Carlo Localization (MCL) application (localize) and path planner (Navigator) as well as map creation and editing tools. The CARMEN toolkit uses Reid Simmon's IPC communication framework, obsoleting BeeSoft's TCX. The down-side is that it will require re-writing all of our software to use it with Zaza :(

Zaza 's replacement belts and motors arrived on the 3rd, but there is a problem the encoder on one of the motors. The new motor uses the current HP encoder technology, and a different cable from the old one. Unfortunately iRobot didn't ship the needed adapter cable with the order, so we have to wait yet another week before it arrives and can do the hardware checkout and qualification before returning Zaza to service.

On a positive note, I spent some time improving the client-server communication schema for the voiceServer and face applet over the last few weeks. The old method used a CGI-based polling technique that was rather slow and inefficient even with mod_perl. The new method uses a Perl POE-based server-side interface (POEfaceClient) to manage each of the connected face applets. This method greatly reduces the amount of handshaking needed to keep current with the voiceServer's cue stack. Another advantage that using shared memory provides is that backward compatablity is retained, so clients connecting through a firewall can still use the old interface method if needed.

The new client handshaking technique required re-writing several key areas of the face applet, so I re-named it zazaface2 so there won't be any caching problems with older browsers. The 2.01 release supports auto-reconnect on socket error, and can now handle server disconnect gracefully. I'll probably add an auto-fallback to CGI handshaking option in 2.02 and put a few of the options as applet parameters instead of hard-coding them.

The Tech received a rather sizable donation of Intel PRO/Wireless 5000 (802.11a and 802.11b) wireless LAN gear and is getting ready to install it. This opens up all kinds of options for Zaza, including real-time high-rate video and audio streaming. I have started the search for a ethernet-802.11a bridge that will alow use of both of the onboard computers, or alternatively a PCI card that has linux drivers available and an external entenna that can be positioned somewhere in the acrylic hood...