We use a Nomadic Scout2 base which is a differential drive robot outfitted with 16 polaroid ultrasonic sensors. The Nomad controller boards manage all the sonar synchronizing, motor control, and power for the motors and sonars. This board connects, via serial, to an onboard embedded computer which reads sonar and odometry information then writes motor velocity commands.
Our embedded system is non-standard hardware for the scout. We installed a single board computer supporting a 1.2 GHz processor and 256 MB RAM. To this we added an IEEE 1394 adapter (more commonly refered to as "firewire") which connects the embedded system to a firewire camera equipped with an omnidirectional mirror. The computer runs SuSE linux with firewire support and the Scout communication daemon. We can connect to the onboard embedded system remotely through an 802.11b wireless ethernet access-point situated on Slammer.
The Scout's power system is not designed to handle this board so we carry an additional 12.0 Ah battery on a platform in the back of the Scout. This battery powers the embedded system through a PC-104 power supply. We can run the onboard computer for roughly 3 hours before a simple voltage alarm circuit alerts us to a low battery. The embedded system's power is "hot-swapable" in that we can connect a fresh battery before disconnecting the spent battery thus providing a continuous supply of uninterrupted power. We have performed this switch many times in mid-experiment thus allowing us to survive late nights of debugging and tackle larger environments. Also, our much faster hardware running in the enclosed space of the Scout resulted in a problem with heat. We successfully fixed this with the installation of an exhaust fan in the top of the Scout, replacing the plate which normally holds the external serial and joystick connections to the Scout hardware. We recommend such an upgrade to anyone who is running a Nomadic Scout since none of our original specification Scouts have ever run as cool regardless of their much slower processors.
The current rate of sensor update is roughly 6 times per second. This is extremely slow due almost entirely to a bottleneck of retrieving information from the Scout hardware through the serial connection (communication events can routinely take 150 ms.) The vision system can run at roughly 27 updates per second, nearly the framerate of the camera (30 fps). This includes grabbing a frame over firewire to memory, processing the image to extract range and bearing to multiple landmarks, and updating the Kalman filter. We are held back by the serial communication since we rely on the Scout board to handle the integration of the odometry. We could use a linear velocity assumption between updates however this would detract from the accuracy afforded us by such a close tie of the encoder information to the odometry integration.