Subjugator Generation 2: Background
|
Following the 1st AUVSI competition, we had an opportunity to
reflect on what we learned, and how we could improve our vehicle.
We classified our ideas into four categories, Power,
Sensing, Computing, and Mechanical.
Power:
Somehow, somewhere, we had to get stable motor drivers. Our
motor driver problem, more than all others combined, hurt us
during preparation for the first competition. It is very
difficult to develop and test control algorithms with a power
system that is suspect (and all to often, guilty) whenever the
sub did something silly. It was almost comical to watch each member
of the team claim that their system was not the reason the sub
was laying on the bottom of the pool.
Sensing:
Up to this point, the sub had sensors for depth, direction,
and pitch/roll. Clearly a true autonomous vehicle needs more
information about it's surroundings to make good decisions. A
wish list was made with items like scanning sonar, vision, an
inertial navigation system, and acoustic communications.
Computing:
Anticipating the addition of the above sensors, we knew a
higher level of processing would be required. Another
consideration was communication with the sub. Previously
communication was only possible when tethered, and then only for
downloading code. The HC6811 mode and reset switches were
controlled via magnetic switches operated by us. This required
team members to swim with, and work in close proximity to a
vehicle that could freak out at any time thanks to its motor
drivers. Remote communication was what we wanted, and wireless
ethernet seemed like something that could made it possible.
Mechanical:
First and foremost, a single, unified electronics
compartment with easy access was mandatory. This allows for
easier debugging, and modular design in the components. We
considered a completely new body, but time considerations
convinced us that modifications to the current body was a better
choice.
|
Page Organization
|
This page is organized as follows: The topics mentioned above are discussed in more detail below.
Additional sections are linked to their own pages. These are things like software structure and
control issues.
Software Structure
Control Issues
|
Power
|
The search began with commercial motor drivers. We considered drivers used
in industry, but cost and size made them prohibitive. Next on the list were
the motor drivers used in R/C cars and such (MIT was rumored to use such a
solution of their vehicle). These also turned out to be too expensive.
Finally, we found a solution.
What we settled on was a small technological
step back, and a HUGE reliability step forward. Rather than using an
H-bridge FET configuration for direction and Pulse Width Modulation (PWM),
we used a relay for direction, and a FET for PWM. The relay has
moving parts, and a finite life-span compared to a solid-state
solution, but it worked, and became a problem solved rather than
one pending. These motor drivers (built in house) have proved extremely
durable, and at about $20 each, quite affordable.
|
Sensing
|
The most important sensor for an underwater vehicle is sonar. We NEEDED
it. We decided on an Interphase PC-View (See Sponsor page) sonar system
that interfaces directly to our computer system via a parallel port. The
Sea Scout transducer is phased array, using a steerable 12 degree cone to
scan across 90 degrees, with an additional downward looking sounder for
bottom finding. The distance resolution is something like 3 inches. Our only
real challenge here (besides sonar image processing) was the interface: The
manufacturers software was written for Microsoft Windows, and our vehicle
was running Linux. Interphase kindly gave us the interface specifications,
and we wrote a unix driver for the sonar. Additionaly, we wrote an
X-windows sofware package that is
capable of operating the sonar and displaying the images. This immediate
feedback allowed us to "see" what
the sub sees, and change our code accordingly. The above figure is a
graphical representation of sonar data collected. It shows a PVC AUVSI
style gate about 16 feet away, and a wall at about 32 feet away.
|
As with the first generation vehicle, a Precision Navigation TCM2 digital
compass was used. It is based upon a proprietary triaxial magnetometer
system and a biaxial electrolytic inclinometer, contains no moving parts,
and can output compass heading, pitch, and roll readings via electronic
interface to a host system.
|
The previous pressure sensor returned a voltage from 0-100
millivolts to represent a depth from zero to 60 feet! The
resulting resolution basically said "According to my voltage, we are
somewhere between the surface, and 1.3 feet deep." We needed better
resolution. We upgraded to a Measurement Specialties Inc MSP-300 depth
sensor rated to 100 psi. It outputs an analog DC voltage between 1 and
5 volts, with each 10 feet of water depth changing, the sensor voltage
by 0.225 volts. For better resolution, we built an amplifier which
produces a 5 volt swing for a depth change of 20 feet. That allows us to
resolve to about 2 inches of depth.
|
Computing
|
The addition of a scanning sonar mandated higher level processing, and
the power to do it in a timely fashion. Our budget, however, did not
allow us to go out and buy whatever we wanted. We therefore, accepted
what was available (for free), and that was an Intel 486SX/33ULP
(Ultra Low Power) evaluation board. This board turned out to be quite
good. It boasts a parallel port, two serial RS-232 ports, a PCMCIA
socket, PS/2 mouse and keyboard ports, a VGA connector, an ISA edge
board connector, the ability to be connected to a standard power supply,
or an external battery supply, and 8 MEGS of RAM.
|
With an x86 processor at our disposal, we decided to run an operating
system, which meant we would need a hard drive. We got a Toshiba 2.1 Gig
laptop drive, and a laptop to standard IDE adapter. Then we had to
select an OS for the system. Our price/performance/efficiency
requirements made that decision easy. Red Het Linux 5.2.
|
Running Linux gave us a multi-user OS that fit perfectly in a network
environment. We just had to find a way to get it on a network. In the
lab, we could plug in a PCMCIA network card, allowing multiple users to
work on the sub simultaneously. In the past, a physical tether was
required to communicate with the sub. Poolside, this became quite
inconvienent, and quite slow. We desired a wireless ethernet style
connection. In steps Harris Semiconductors. We recieved an evaluation kit
for the PRISM wireless ethernet cards. These cards are intended for
design engineers testing the technology for possible inclusion in a
product of some sort. What that means is that we had the flexibility of
adding our own antenna. We placed the card in the sub, and ran the wire
through the hull to an external antenna. During all development work, we
placed the antenna on a styrofoam cylinder that could fload free (the
wire is 8 feet) behind the sub, and could therefore relay sensor data in
real time. For competition runs, the antenna is mounted on the hull, and
communication is lost during submergence.
|
Mechanical
|
The addition of all these electronics meant we needed more room, ie. a
bigger electronics compartment. We also decided that a single, unified
compartment better served our requirements. We worked on a layout to
determine our space requirements. This image shows (starting at the
bottom) four mechanical relays, to control direction of the four motors.
On the right of that is the electronics battery, with the motor driver
circuitry below it, and the Motorola 6811 near the bottom. The right side
of the image shows the hard drive (silver), and under it is the Intel 486
board. At the top of the image (black) is the Interphase PC-View sonar
controller. To the left of that is the Precision Navigation TCM2 compass.
To the left of the compass are two Burton waterproof connectors. Once the
dimentions were finalized, we made the box out of 1/4 inch aluminum plate.
|
For a vehicle this size, safety is something that cannot be ignored. A
kill switch is required. When we are in communication with the sub, we
can stop it via software, but we cannot assume that will always be an
option. Therefore, we required a physical kill switch mounted externally
that, when activated, would interrupt ALL power for the motors. We wished
to find a way to do this without also shutting down the computer, since
shutting down a unix machine without warning is not a good thing. Since
we isolate our computer / motor power systems, this turned out to be not
that difficult. We simply ran the power for the motors through a Single
Pole Double Through (SPDT) relay, and used the waterproof switch to
control the throw on the relay. When the kill switch is pushed, the relay
throws and the motors get no power regardless of the computer commands.
This switch is a medium power (about 6 amp) switch from Giannini. We use
a similar switch to power our electronics.
|
Water leaks was a fact of life for the Gen One sub. Since we were
completely upgrading all of the electronics, a water leak would be worse
than ever. The estimated value of our electronics went from $800 (Gen One)
to about $3800 (Gen Two). That box needed to stay bone dry. In the past,
the connectors were the real problems, so we looked far and wide for
connectors that would solve our problems. Burton Electrical Engineering
was our answer. Their connectors, in our eyes, are the best built objects
on the sub. These things are simply amazing, and the connectors are now
the last thing we worry about.
|
|