Overbot status as turned over to the University of Santa Cruz

On-vehicle hardware

The hardware on the vehicle is generally in good shape. There are some items that should be dealt with.

Power supplies

One of the 24VDC power supplies has a damaged connector, which is being held in place with a plastic shim. It has been holding together well but should be replaced.

12VDC power should always be turned on before 24VDC power, or the tilt head and steering will run into their limit stops and stall. This occurs because the controller interface boxes, which provide optoisolation for the limit switches for some devices, run off the 12VDC supplies. It would be useful to wire the 24VDC power switch to get its power from the outputs of the 12VDC switch.

Back bed ventilation

Field testing has made it clear that the back bed needs ventilation improvements. First, the back bed is filling up with dirt because the generator's built-in fan is sucking air in from the bottom, not through the filters on top. Two 24VDC blowers are being provided with the Overbot, but they're not installed. The back bed needs enough blower power to pressurize it slightly, so that dirt is expelled.

Second, the computer box has one single-board Pentium IV machine with the cover off inside. If the cover is on, the computer will overheat and burn out within two hours of generator operation, due to bad airflow design of the computer's case. (Contact Damon Cronin at Tri-M to discuss this.) The computer boards are industrial-grade and rated to 70C, but they actually exceed that temperature in the field. The computers need extra cooling, especially if two computers are installed in the back bed. The mounting rods for the stack of computers will accomodate three computers, but we've never had more than two in there. The best solution is probably to mount two computers, but with extra space between them, and put an exhaust fan on the lid of each, above the CPU's fan, with extra holes drilled in the lid.

Tri-M will fix these computers if necessary, but they have to be shipped to British Columbia and back. This takes weeks. Overbot owns three of the machines, so there's a spare.

Vehicle

The vehicle needs a wheel alignment; front tire wear is uneven.

Note that if the steering centering changes, it's necessary to recalibrate the steering centering. This is a constant in the Galil controller program for "gcsteer".

Operation of the vehicle

There's a bright yellow laminated card which gives the basic operating procedures for the vehicle. But this was for DARPA's personnel, and doesn't describe how to create or load a waypoint file, or even how to start the software.

The general idea is to create a waypoint file in DARPA's format, put it in /home/vehicle/waypoints on gcrear0, run the "usercontrol" program on gcrear0, select the desired waypoint file with the menu in "usercontrol", set "active" mode, set the E-stop radio transmitter to "on" and "paused", set the "auto/man" switch on the dashboard to "auto", and do a "reset" in the "usercontrol" program. Then exit "usercontrol". Stand clear of the vehicle, and set the E-stop transmitter to "run".

New waypoint files can be created using the vehicle and the "gpsins_gui" program, run remotely over the WiFi link. More on this later.

Software

The software is all in C++, and is maintained under CVS. More on software turnover later.

The basic architecture of the real-time system is that programs run under the "watchdog", which starts all the programs, helps set up their interprocess communication, and monitors them to detect if any program exits. The "watchdog" uses "start files", which list the programs to be run, their priorities and IDs, which CPU the program runs on, and their parameters. There's one main start file for the vehicle, and it runs on "gcrear0".

Networking

The Overbot uses Ethernet with TCP and UDP over IP. It also uses QNET, QNX's native networking, which runs over Ethernet but is not based on IP. (It's possible to run QNET over IP, but the Overbot isn't currently configured that way.) There's an on-vehicle network, as follows.

The IP addresses on the vehicle are permanently set into each device. There is no DNS server on the vehicle. All machines that talk to the vehicle network need an /etc/hosts file. The vehicle's IP address space is from [10.100.100.128] to [10.100.100.255].

The vehicle has a WiFi bridge (802.11g with WEP encryption) for diagnosis and testing. The Linksys boxes (there are three, one on the vehicle, one for field testing, and one for shop use) all run Linux-based software from Sveasoft. This software has major defects; when too many packets (more than two) are in flight, it garbles the third packet. High error rates and delays occur frequently. This software needs an upgrade, or outright replacement.

An external Ethernet cable can be plugged into the rear of the vehicle to connect its network to the wider world. For any bulk transfers, like program loads, this may be necessary.

Make sure there is a firewall between the vehicle and the public Internet; you don't want some spammer talking directly to the motor controllers.

The main computers, gcrear0 and gcrear2, can be reached using "ssh". The real time system runs as user "vehicle". They can also be accessed using QNET, QNX native networking, which is how they talk to each other. "lmsserial" is accessed with TCP, and the Galil controllers are usually accessed with UDP, although they understand TCP as well.

For test purposes, there's a command-line program, check_controller, which allows direct communication with Galil controllers. With no options, check_controller provides read-only access to the controllers and won't issue motor commands. The "-w" option allows issuing motor commands, downloading controller programs, and changing parameters.

Equipment

In addition to the Overbot, we're transferring the shop equipment and tools that go with it.