Date: Fri, 20 Jan 2006 02:02:49 -0600 (CST)
Subject: drill motors wired and USB DMA options
X-UID: 125
Content-Type: IMAGE/JPEG; NAME="img2560.jpg"

The wires from the drill gear motors and power MOSFETs are soldered to 
longer 18 gauge stranded wires and solderless ring terminals crimped on 
the ends. It's funny as I'm almost out of these ring terminals. The bag 
had 100 count. Through use on the robot and mistakes, I've almost expended 
all of them. I wouldn't have believed it a few months ago.

The ring terminals are screwed into the terminal block. In the photo, the 
twisted black and white pairs are from the gear motors. The twisted red, 
white and black triples are from the power MOSFETs.

I took a piece of toolchest foam I had laying around and wrapped it around 
the battery tray. It seems to stick pretty well and hold the batteries in 
place. Still, velcro might be safer. The problem with velcro is how to 
apply it and not block the vent holes on the bottom of the battery packs.

I did some more research about PCI bus mastering and DMA instability. It's 
a common occurrence especially with streaming video. People with homebuilt 
PVRs (a Linux based super Tivo) often run into this. Hardware is not rock 
solid. When data bursts are very high, the system becomes unstable. This 
typically involves a mixture of streaming video from a framegrabber, heavy 
multi-gigabyte file transfers over a fast network interface, and a high 
bandwidth USB device like a webcam operating at the same time. It's tricky 
to get everything working without intermittent system lockups.

Basically, this is a hardware problem. Sometimes device drivers work 
around this problem. Careful tuning and configuration of a system is also 
involved. Often, these software approaches work by throttling the system 
data rates to a level where the lockups don't happen.

Anyway, I just don't have the time to spend tuning the robot's onboard 
computers and testing for a stable configuration. I could spend weeks 
without happening upon a combination that happens to work. Worse, if I 
ever need to make a change, then the system may become unstable again.

The obvious solution is to run each webcam off a separate computer board. 
The electronics enclosure has two computers. I had intended for the 
computer connected to the motor controller and 900 MHz radio to be the 
executive. It was the high reliability board that dealt with system 
monitoring, management, control and communications. The other computer was 
for sensors, especially image processing, localization and navigation.

But what I think I'll do is split the cameras, one per board. This has two 
advantages. One, I know it is a stable configuration. Two, the frame rates 
are higher. I won't have that problem of two cameras cutting the frame 
rate in half. However, I will have much more network traffic between the 
boards. The network interfaces are 100 Mbit so should be ok with this. The
extra interrupt activity hopefully won't impact the executive board too 
much as all of the computationally intensive image processing will be done 
by the other board.

Yes, I know that this is kind of the like left/right brain bilateral 
hemispherical design in mammals. It has just turned out that way by chance 
of how this robot design has evolved. It must be this way as I couldn't 
get it to work any other way with what I've got.