Date: Wed, 9 Nov 2005 02:06:03 -0600 (CST)
Subject: more excitement - motor control board not working
X-UID: 102
Content-Type: IMAGE/JPEG; NAME="img2395.jpg"

I'm going to throw out the motor control board and re-do it. I can't waste 
more time. I need to get the robot rolling early next year.

When I designed this board, I had the idea that lots of connectors would 
make for a flexible design. It's analogous to software design that is 
over-engineered with many modules, layers and interfaces to handle any 
possible need. The result is usually a system that is so complicated that 
it can not be understood. It is too flexible.

This is the way of design when you do not know what you are doing. I've 
just made so many mistakes. I look at this and wonder how I could have 
been so crazy. Many of the design elements are very difficult to execute. 
It made the problem much more difficult than it had to be.

My back-up plan is -

1. No H-bridges at all. Just use the existing power transistors that came
    with the Panasonic drills. The upside is a very compact design with
    efficient cooling of the transistor and a heatsink that fits inside the
    drill body.

    For reverse, use a DPDT relay to switch the polarity across the motors.
    This is simple in that I can get everything I need locally at Fry's,
    Radio Shack, or Altex.

2. Bipolar transistor based circuit for the steering motor. The upsides
    are low voltage operation (it is a low voltage motor) and reduced parts
    count. There really isn't any downside. FET based motor control doesn't
    make sense for low voltage servo-type gear motors.

The above is less expensive, has fewer parts, and probably more reliable. 
So why didn't I design it this way in the first place? Because this is my 
first electronics project and I don't know what I am doing. Also, 
sometimes necessity and deadlines force practical thinking. I was in blue 
sky mode a few months ago.

Where the robot is now -

1. vehicle platform fabricated
2. computer board systems software ok
3. microcontroller ok
4. sensors work

If there is a week or two lead time on the new motor control solution, I 
can spend that time integrating the 900 MHz Maxstream radios and the 
Garmin GPS receivers to the computer boards and laptop.

In hindsight, deferring the microcontroller firmware was a huge mistake. 
The proper order was:

1.  vehicle fabrication

2.  computer boards system software
2a. testing

3.  microcontroller firmware
3a. testing

4.  electronics prototyped
4a. testing

5.  electronics board and enclosure fabrication
6.  vehicle assembly
7.  software development

I did step 5 after step 1. Then I did step 2. This was a big mistake. It 
was born of my waterfall notion that I could do all of the fabrication, 
then all of the electronics, and then all of the software. The problem 
with this approach is that many faults are not detected until integration 
of all systems. I tried to build each layer separately. But what I should 
have done is build vertical slices through the system.

The microcontroller work was deferred as I thought it was a known 
quantity. In reality, none of the power electronics could be tested 
without the microcontroller. It serves as the interface between the 
computer boards proper and the power electronics. So it was a critical 
part of the project. Only now that I have a reliable microcontroller are 
other failures visible.

My criteria for the next motor control design are -

1. Simple
2. Reliable
3. Low parts count
4. Easy mechanical assembly

I don't care so much about cost or any perceived notions of flexibility. 
If the parts count can be reduced, then it becomes simple enough to be 
flexible. I'll need to have a simple design by the weekend so I can get 
more parts.