Older blog entries for rudybrian (starting at number 15)

Time for another update...

Since the launch last month we have run Zaza every Saturday. As expected, we ran into a few minor problems, but have worked most of the kinks out by now.

I put together a few Perl scripts to push images from behind the museum's firewall to an outside web server. Eventually this will be done by more efficient means, but the existing system works quite well. Video from the control room and from the robot (when online) is available here.

I managed to clean up a few more bugs on poslib's simulator, and added automatic timeouts to visited goals. This allows testing without manual intervention for visited goal reset.This thing is nearly ready for public testing...

Just a random note: My old HP 1722B oscilloscope looke like it is ready to give up the ghost. I can no longer focus a trace on the CRT, and after spending some time poking around inside, it looks like the CRT is failing. The tubes are no longer available, so it seems as though it is the end for this scope. I did some research on the availability of stand-alone (with PC-connectivity) and USB scopes, and was very dissapointed with the offerings (and prices). It seems test equiment market is a bit behind the times and are just now beginning to offer connectivity options like USB and ethernet. In my searches, I found references to the BitScope in a 1998 article in Circuit Cellar, a few Linux UG's and a few PIC developer sites. This thing is impressive. It's a two channel, 100MHz, PIC-based oscilloscope and 8-port logic analyzer with a 115k serial port. Both Linux and Windows applications have been written for it, and it's under continuous open hardware and software development. A kit is available for $250 on the BitScope website.

I spent some more time on the applet JScrollPane buffer overflow bug and found a workaround. Skipping the next screen repaint after changing the zoom level seems to have resolved the problem.

Next Saturday the 29th is the official rollout of the Zaza public program at the Tech Museum. The online program schedule can be found here. We are initially deploying with Phase II functionality. This will allow the program to evolve as additional features are added.

After the incident on the 11th, I started reviewing some of my earlier research on 3 and 4 rotor VTVL platforms. Something tells me that both teleoperated and autonomous plaforms of this type will have a strong role in the days to come...

Links

  • MIT Zero G Eye
  • FFMP Bookmarks
  • Sikorsky CYPHER
  • Build your own Roswell Flyer
  • Commercial 4-rotor version
  • Ian's GizmoCopter
  • OpenVTVL

    I was able to make some headway on enhancing Zaza's Java map applet this past week. I added much-needed scrollbars allowing proper resizing of the applet window, three zoom levels, and auto-tracking. Each is user-selectable from buttons on a simple toolbar (see screenshot) There is one lingering bug that causes a buffer overflow under certain circumstances, but happens fairly infrequently. I also slapped together a CSS page, and some content pages for a simple user interface.

  • The public tests on Aug 25th and 26th went quite well. The museum was fairly crowded, and provided an ideal worst-case testing environment. On the 25th the museum had live bats nearby where we were planning to run Zaza. During a startup test the robot began firing her sonars and the bats went berzerk! Fortunately, they didn't seem to mind when we operated the robot a little further away.

    The simulator is coming along nicely, but still needs some work before public testing can be allowed.

    I have started work on enhancing the Java applet to give client-side control of map zoom level.

    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?

    6 older entries...

    X
    Share this page