Success of the motor control circuit

[Tim Vanderhoek <vanderh@ecf.utoronto.ca>]

 ...  was less than stellar.

But it does work.  Several notes:

 - The comp board is very sensitive to having a truly common ground.
I found that it would crash and/or reset quite easily.  The protoboard
isn't great and that probably didn't help.

 - The comp board is very resilient to voltage losses.  I could stall
the motor, thus causing the power supply to go "beep beep beep" and
the comp board would still function properly.  Impressive.

 - I need the male db9 connectors to make future testing easier.
Accidental short circuits due to trying to connect wires to the ports
were the cause of some of the comp board crashes.  Alternatively, we
can solder the db9s to something useful.

 - The thing as a whole is a little finicky.  It is good that
we're using wheel speed feedback, because the motor speed+torque is
not too consistent (although that may improve once connections are
soldered rather than just twisted together).

 - I didn't test the forward/reverse or the left-hand side (for some
definition of "left" :) motor circuit.  Presumably there should be
nothing interesting for those to test.

 - In general, PWM control of the motor didn't work as well as I had
expected.  I was going to try doing the pulses at some higher frequencies,
but my modification to do so accidentally made the frequency lower and
I didn't want to wait 1/2 hour+ to erase the eprom.  At current
frequences (~80ms period) the motor vibrates noticeably --- I think
this is far too slow a period.  For sufficiently long periods,
the current draw of the motor appears to increase very sharply.

 - When I connected lines from the +5V supply to the comp board, the
comp board promptly crashed.  It worked fine if I connected them from
the +5V supply through a 10K resistor and then to the comp.  I don't
know why.  10K might be a little bit big.  I didn't try connecting any
input comp pins from the driver --- I probably would've tried this if
I'd thought of it.

 - The motor control input would randomly recieve occasionally one long on
pulse that lasted ~1/10 a second (just judging from the sound the
motor made).  No idea what was going on --- I speculate that this was
a problem with ground, again.  It could be an internal comp board
problem, too.  It's too erratic and the software's too simply for it to
be a software problem, I think.

 - My soldering iron is in really bad shape these days --- I
accidentally left it running at very high temperature for several
hours and totally forgot about it.  Oops!  :-)


Given all of the above, we may at some time need to reconsider our
decision not to use a watchdog circuit.  I played around with
interrupts on the board, and they worked like a charm.  It probably
wouldn't be too hard to generate a watchdog circuit, but I'd much
rather we avoided crashes altogether --- crashing means a short delay
where the robot recovers and means that input information has been lost
(unless I add magic to let Qubit know that it has been reset by a
whatchdog circuit and that it should not invalidate any ram
information, but this is risky, since if the comp crashed, than that
ram information could be highly invalid --- it could even be related
to the cause of the crash).


And some other good news besides the interrupts working like a charm:
it appears very difficult to actually destroy 6522 via chips.  Malone
is concerned about groups blowing them ... I can only see this
happening due to accidental application of 12 volts where a 5 volts
supply was supposed to go.


-- 
Signature withheld by request of author.