Older blog entries for rudybrian (starting at number 11)

Two new Zaza public test dates have been announced: Saturday August 25th, and Sunday Aug 26th. This is in conjunction with 'Aibo Naming' events scheduled to begin at 2pm both days. Zaza will be running from 1-2, and again from 3:30-4:30 both days on the lower level of the museum.

I am working on a simple simulator for poslib to allow some initial load testing and rough approximation of the robot's behavior when operating. This will let me test out the voting system and applet functionality under expected load conditions without the robot hardware online. A link will be posted shortly...

17 Aug 2001 (updated 19 Aug 2001 at 20:01 UTC) »

Moving ahead...

The 8/16 localizer test went almost flawlessly. Zaza was able to navigate sucessfully between any point in the lower atrium and Explorations gallery (see map). During the test there were many people in the area in near proximity to the robot. They caused the planner to make many slight course corrections, and eventually reached the intended destination. There was one minor collision noticed during testing with an obstacle that was not fully visible to the laser during the scan. The planner plotted a route too close to the object, and the robot skimmed it once, but corrected when the IRs or bumper switch registered the collision.

I was unable to test the latest web control Java applet while in the museum due to an unrelated software problem with the development workstation. Later in the evening I did a trial run in the office building with a small map with three goals I was able to verify goal voting functionality end-to-end. Client votes are tallied on a per host basis to allow an unlimited number of clients to vote on a destination. The voting schema at present choses destination with votes >= the mean number of votes and sends them to the planner.

Good stuff... Hopefully you folks will be able to try it out for yourself not too long from now.

Bad news and good news...

We had to cancel the 8/9 Zaza Phase II test after discovering that the baseServer wouldn't start up. We also made the mistake of installing an untested version of the face application with limited voice recognition capability. It crashed constantly, but when working, the recognition engine worked quite well. I spent the rest of the day poking around inside the robot and was able to determine that the cause of the problem was a loose cable on one of the MSP boards. Apparently the ribbon cable had wiggled out of the IDC connector just enough to be intermittent. I must have torqued it a little too much when installing the replacement +5V DC-DC converter on Monday. Hopefully it won't happen again. To make up for lost time we will be doing two tests, one this Thursday (8/16) and another next Friday (8/24).

On 8/10 I was able to get the first version of the poslib Perl interface compiling and partly operational. Today (8/13) it is fully operational with a test map (position plotting only). The bug with Shareable's freeze() and thaw() serialization routines is in fact a bug with IPC::ShareLite's documentation and nothing more. Position data is now hashed and serialized before being stored in shared memory which should be much faster and more efficient than the string parsing done previously. I also fixed some scaling and offset problems with the Java applet that weren't noticeable before.

Mike was able to clean up some of the bugs and reduce crashing on the face last Friday, and we should have a usable version by this Thursday. I hope to have versions of the applet, poslib and localizer interface that support limited goal submission as well but have a lot of work to do to make this happen. Fingers crossed...

7 Aug 2001 (updated 14 Aug 2001 at 03:19 UTC) »

I finally found a secure and scalable way of interfacing the C-language localizer and the Perl-based map applet CGI interface yesterday!

The cleanest way of doing this would be using perlxs but my initial attempts using this method were thwarted by a rash of unintelligible linker errors. They were most likely related to the TCX library which uses some signalling types not supported by the Perl API.

The next-best method involves adding Perl interface stubs to a native C-language localizer client via perlembed. The localizer client will be able to push variables onto the Perl stack and call Perl subroutines directly. The client will poll for goals or other client-side information. Because our CGI is not persistant (not running constantly) and (possibly) not running with the same user credentials, it must have some means of retreiving the variables. This is accomplished with the IPC::ShareLite module. This way when the CGI executes it can quickly pull the variables from shared memory and return them without hitting the file system or creating a measurable burden on the server regardless of the number of clients.

I did run into a problem though. Since IPC::ShareLite only understands strings and scalar data types, to store and retrieve the variables (as a hash) from the shared memory space, they must be Shareable::freeze()'ed first. For some reason, doing this discards the hash key, rendering the data unretreivable. This is probably a bug in the version of IPC::Shareable I have installed. I did a really kludgey workaround and was able to sucessfully pass data directly from a compiled C program to the Java map applet running in a browser window.

Slow progress is still progress ;)

I have spent that last two weeks working on a map applet that will allow web visitors to select tour goals and show Zaza's position in the gallery. It's been a while since I last worked with Java and this has been a great incentive to catch-up with the latest Java 2 stuff. I still need to write the back-end support hooks to the planner and localizer. Here's a screen shot taken after adding basic goal point plotting.

We are planning another public test on August 9th in the lower atrium of the museum. If you happen to be in downtown San Jose next Thursday afternoon and want to see Zaza, let me know...

We did another public test in the museum's lower level on 7/19 after doing some tweaking of the reaction module. I grabbed a screenshot of the latest web interface during the test. Definite progress, the kids went nuts.

Later that evening after the museum had closed, I did a test run of the localizer, planner and detection modules. Localization worked great, and the planner worked well. There was one collision with a dynamic obstacle, the cause of which is not currently known. The robot only turned away after the bumper switch was triggered, but the obstacle was visible to both IR sensors and the laser scanner long before the collision. Using the probability map generated by the localizer for entropy comparison, the people detection module hardly worked. Perhapse the more recent methods will be of benefit?

Its been a while since the last update. I did a full scan of the Innovations and Cyberplace areas of the museum on 6/25 before leaving on my dive trip. For comparison, here is the old one from 1999.

I came up with a few new ideas during my vacation for phase 5 of the project. They will need some concept verification before I'll know if it will be possible to proceed in that direction.

This Monday's mapping attempt was only slightly more sucessfull than last time. The particular mapping approach we are using just doesn't work all that well in cube mazes. Too many of the corridors and aisleways are long and featureless, coupled with odometric drift, the results are marginal at best.

Map-building in the museum is another story. The unique architectural and exhibit features provide a wealth of points that the feature integrator can use to correct odometric drift. The resultant maps are beautifull, as the map I scanned this evening in the Explorations gallery can attest. Hopefully, I can find a fast standardized way of generating VRML's from these maps, this one needs over 575M of RAM to render, and an extremely fast multiprocessor machine. Rendering stills in Povray just isn't good enough...

15 Jun 2001 (updated 16 Jun 2001 at 05:09 UTC) »

I was able to spend some more time with the latest version of Beesoft from Sebastian on Zaza yesterday morning. Previous attempts at compiling and using the code directly on the robot resulted in application crashes or poor quality maps. The older Linux version has a few header files in different places than modern distributions, and required a few tweaks to compile. I decided to start recompiling everything from scratch to ensure that any existing binaries compiled on later Linux versions were removed. Apart from one problem with the latest version of LOCALIZE, everything appears to work properly now. There have been some significant enhancements to laserServer, laserint, LOCALIZE, and map that are not backwards compatible with earlier colliServer versions, and thus were causing the problems discovered during earlier tests.

I made a test map by joysticking the robot around a small wing of the Tech office cube maze and then ran LOCALIZE, plan and laserint on the offboard development computer with the acquired map. This time it worked flawlessly. I was able to start the robot in a known position and orientation, and it was able to successfully navigate to another point on the map autonomously. Ahh, progress :)

We did another public test(pictures: 1,2,3) of Phase II mode on the lower level of the museum in the afternoon. Far more children and family groups came through the area during the test, and the results are very encouraging.

After the test, later in the evening I attempted to map a much larger part of the McCabe hall facility by the same means as before. Unfortunately, my choice of a random path through the halls (and not actively watching laserint during the map's construction) caused laserint to fail, and produce this map. I'll try again next Monday evening.

If anyone is interested in the techniques used for mapping and localization, several papers were written on Zaza's predecessors RHINO and MINERVA, which have a significant amount of information.

I have upgraded the news collector engine on my primary webserver from WebFetch to NewsClipper. WebFetch hasn't been updated in the last few years, and several of the modules are broken. NewsClipper provides an API for developing your own handlers, which makes the development of new ones quite easy.

I haven't yet found a single, comprehensive source of up to the minute robotics news. Several sites like robots.net, and Robots and Robotics News on Yahoo do a decent job of pruning through the mess of news from AP, and print news sources, but the the results are all done by hand. I am willing to put up with semi-unrelated news, if it lets me see robotics-related news faster. As such, I wrote a handler for NewsClipper that uses Yahoo's news search engine to troll for up to the minute robotics news (my test page is here). Sometime in the next few weeks I'll be transforming my main robotics page into a robotics information portal so that others may take advantage of this information resource.

2 older entries...

Share this page