Machine Intelligence Laboratory

Subjugator Generation 2: Background

subjugator 2
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


Sonar Display

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.



Precision Navigation TCM2

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.




Pressure Transducer

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


Intel 486

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.



Toshiba Hard Drive

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. Red Hat Logo



Wireless Ethernet

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


Electronics

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.



Kill Switch

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.



Burton Connectors

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.