In the meantime, we have added some image mosaicing software to our map-building robot and can now produce (with some manual help, at the moment) Quicktime VR mosaics representing the environment being explored. For an example, see
We have developed a server/driver program to facilitate the communication among the Sick laser sensor, a SeaLevel fast serial card, and our building exploration software. We call this program the Sick Laser Server (or Sick Daemon). The goal of the Sick server is to reduce the amount of knowledge the high-level software modules (and their designers) must have about the sensor operation. The server allows the connecting clients to assume they are reading data from a device resembling an ideal sensor.
The server offers the following capabilities:
One of the biggest benefits of the server is the possibility of extracting polylines on board the robot. This reduces the amount of data transmitted to the operator or to a `next-best-view' program running in a remote machine. Moreover, geometric algorithms that assume structured outputs from a range-sensor are now easier to port to a working system.
The fast sensor speed allows improved 3D data acquisition when the laser sensor is mounted vertically, as the robot may sweep the environment at a higher speed. We are now expecting a rate of about one spherical 3D image with 0.5 degrees of resolution every 24 seconds.
Finally, in order to allow interaction between the robot sensor and clients running outside our LAN we have developed a simple `portal' program. The portal serves as a proxy between the client and the Sick server. Proxies are required on a system whose software components are not entirely running on the same side of a firewall.
The controller that moves the robot from milestone to milestone (as commanded by the planner) has been tested on the target tracking robot and is working. We are are currently integrating the controller with local collision avoidance software based on sonar readings. We are also reworking the interface between the high-level planner and the controller to allow more asynchronous operation between the two and provide error-recovery in case, due to obstacles or other difficulties, the controller fails to take the robot close enough to its commanded location.
Our currently implemented target tracking algorithm attempts to maximize the escape time of the target. We are now considering strategies to follow, if and when the target does escape. We would like to respond to that eventuality in a way that takes advantage of the observed locations and behavior of the target; we fall back on our general target finding algorithm only as a last resort.
We have continued to experience some hardware difficulties with the target tracking robot. It seems that the voltage driving the hard disk in the on-board system drops below the allowed threshold, and as a result the disk become unreadable. This maybe because the fans we added to cool the motherboard draw too much power. A resistor replacement has fixed this for now and we are actively working on a permanent solution, with Nomadic's help.
Julien Basch, the postdoc we hired from Duke University to replace T.M. Murali has arrived.
We have produced a report on the performance of the techniques developed so far. This can be found at