2006 competition video

22 02 2007

There were static cameras at the bottom of TRANSDEC capturing video throughout the competition. These are not those feeds. Instead, a Navy diver with an underwater video camera recorded this video during a testing session.

Software architecture

20 02 2007

After hashing out all the hardware-software intricacies, we’ve constructed a service diagram (a class diagram, essentially) for all the high-level software. MS Robotics Studio lends itself to an object-oriented design where MSRS services are the objects. Though it is guaranteed that each service will contain several classes, the “service view” creates an easily comprehendible starting point.


Starting from the simplest end, each sensor service at the bottom represents a sensor (obviously). These services are intended to relieve the rest of the system from the burden of low-level communication. They handle serial communications, data packet encoding/decoding, timing issues, access issues, and any other low-level tasks that might benefit the rest of the system. For example, the cameras we are using this year are not plug-n-play; they must be accessed through the manufacturer’s SDK. The CAMERA service adds an element of acquisition transparency so all the other services may grab camera data wihout having to mingle with the manufacturer’s code.

Each of the sensor services feed into a cloud called “Sensor Fusion.” In an earlier post, I explained sensor fusion as a way to intelligently combine sensor data into valuable information. The sensor fusion cloud represents the set of services that either extract information from the data of one sensor, or extract information from a combination of data from several sensors. The NavGrid must subscribe to each of these in order to receive the processed information.

NavGrid and Arbiter subscribe to each other so that 1) Arbiter can trigger an event to request specific information from NavGrid, and 2) NavGrid can broadcast general information to subscribers. The intent here is to enable Arbiter to make special information requests while still allowing NavGrid to broadcast its state to subscribers. NavGrid’s state information may contain all events on the absolute navigation grid, or maybe only obstacles and interests in its immediate area– the exact structure has not been decided. As an example of specific information, Arbiter may ask for the interest closest to SubjuGator’s current position.

Arbiter makes all the important decision regarding movement, mission planning and control, and any other task that might require human logic if SubjuGator were manually controlled. The blue square representing the Arbiter displays only a stub for the purpose of this high-level abstract. In actuality, the Arbiter will be composed of several services– I will provide further detail about this in another post.

NavActions subscribes to Arbiter in order to recieve navigation commands. Arbiter will issue navigation commands as changes in state. That is, when Arbiter changes the state of SubjuGator’s current course (40 degrees at a speed of 50, for example) to a new course directive (stopped, facing 35 degrees), the service will broadcast the new course of action to its subscribers. Only the subscribers that can handle such a message will accept the broadcast (so, NavGrid will discard this message). NavActions works with the underlying embedded thurster-driver board to move the sub.

It has not been decided which services will benefit from the Heartbeat service yet (hence the barrage of anonymous subscribers to it), but the idea stands that a heartbeat message would prove useful by acting as a relative clock for interested services and checking system status.

For debugging purposes, the NavGridGUI will be able to subscribe to the NavGrid merely as an observer. This will allow us to see what SubjuGator sees in regards to mission interests (for example, an orange pipeline). Also for debugging purposes, NavActions subscribes (indirectly) to the XBox 360 Controller, which allows the operator to manually control the movement of SubjuGator. The speed/dir mappings service, as you notice, connects NavActions and XBox 360 Controller. This service is necessary to map values fired off by the controller to actual speed and direction values accepted by the underlying embedded thruster-driver. The speed/dir mappings service could have been merged with either of the services adjacent to it, however past experience tells that speed and direction mappings (more so speed) will change often to accomodate different environments. Where in the test pool we want full throttle to be a safe speed that will not throw SubjuGator into a nearby wall, the TRANSDEC is much larger and full throttle should efficiently drive the sub from one end to the other.


2007 preliminary competition rules revealed

9 02 2007

Just hours ago, AUVI’s Angie Carr released a preliminary version of the 2007 competition rules. Interestingly, the mission objectives consist primarily of a permutation of last year’s objectives. Additionally, there exists a task that involves releasing buoys and another that involves picking up a “treasure.” But mission objectives aside, the most interesting point remains: event organizers are giving competitors only five months notice. The competition kicks off on July 11, 2007.

Without regurgitating the entire rule book to you, here are some of the highlights:

  1. Competitors are tasked with bumping into positively buoyant buoys that blink at some rate over some period. The mission specifications do not note a reason for the complicated blinking pattern other than to identify that the object is a buoy.
  2. The pipe and bins are back. Traditionally, pipe has been extremely easy to detect while bins have been extremely difficult. This is primarily due to the fact that color classification schemes are easy to implement and therefore used widely. However, dynamic modalities of classified objects tend to thwart such schemes.
  3. Competition logisticians have reintroduced the dockign station– a red, blinking light the sub must dock with, or nudge. Only three teams accomplished this last year, one by chance. Uniniversity of Florida was, indeed, one of those teams.
  4. In years past, subs have been tasked with retrieving an object at a specified location. This year, that object is a three-dimensional “X” made from PVC material. Whether teams accomodate their subs to accomplish this task will largely depend on its point value and who else can do it.
  5. AUVSI posted new 2008 weight limits shortly after the 2006 competition, implying that weight would play a huge factor in coming competitions. True to this implication, the bonuses for lightness this year are huge (bonus of 100 + (70-lb)^2 for subs weighing less than 71 pounds). By this year’s standards, last year’s SubjuGator model would earn 1300 points just for showing up!

SubjuGator has a long and arduous swim ahead of her.

A recap of last year’s competition

8 02 2007

Some of you reading this may not be aware of SubjuGator’s primary purpose. For the past 9 years, each generation of SubjuGator has competed with other institutions around the world in ONR & AUVSI’s Autonomous Underwater Vehicle competition. The directors of the competition present teams with a set of tasks that they must complete autonomously within some time limit. Other restrictions, such as a weight limit, mandatory shrouded thrusters, and an accessible kill switch, apply also.

On top of these basic rules, each year AUVSI instroduces a set of mission objectives that yield points upon completion. Months before the competition, AUVSI publishes the detailed mission objectives to their website. Without all the nitty gritty, the course resembles the picture below.


The TRANSDEC (pictured above) is a large, man-made, concrete “lake” with a small metal building suspended over the center. The large blue circle in the middle is an acoustic sound trap– this part reaches depths of approximately 40 feet. The walls fall toward the bottom in an elliptical manner, as you might expect. ONR provides a team of Navy divers to set up the course, control the lifts that insert and extract the subs into/out of the water, and swim with the subs to observe their progress along the course.

Teams have 15 minutes to make it through all the cartoonish obstacles in the picture. The first of the multicolored elements littering the diagram above, at the very bottom right (the start of the course) on the competition side, is a floating dock (yellow square). From here, the diver activates the sub (usually the inverse function of the killswitch). The mandatory first task in this mission was to pass through a gate, represented by the white bar. Easy as it sounds, it’s a highly efficient way of filtering out the teams that would not do so well at the more complicated tasks. Once through, the sub had to (optionally) interprest a random order light array (the checkered rainbow passing underneath the white bar), nudge a blinking light deemd the “docking station” (red circle), follow a broken orange pipeline past a series of bins (white/black rectangles) distinguishable by the angle of lines (or the lack of lines) printed on their faces, and locate and surface above an acoustic pinger. The competition logisticians used different frequency blinks on the random order light array to tell the sub in which bin it should drop a marker. If the sub did not detect the random order light array, it could drop the marker in any bin for a significant point reduction.

SubjuGator placed 1st above Duke followed by Ecole de Technologie Superieure. Still, no team for the past two years has come close to completing the pipe/bin task.

The final design (tentatively)

7 02 2007

The final design is in! Now that we’re in possession of all SubjuGator’s components, we can accurately plan for the weight distribution, space consumption, and any other limitations of said components. After weeks of each department (electrical, mechanical, and computer engineering) putting in their two cents, everyone agreed on this design:


The aluminum hull dissipates heat build up from the internal electronics. Also, stronger than Lexan, SubjuGator will be able to dive deeper sans worried engineers. An external aluminum “cage” supports the hull on dry land and also acts as mounting point for external sensors such as cameras. Since aluminum lacks the transparency of Lexan, the cage must support the cameras.


The DVL rests at the center of the turning axis to avoid unnecessary coordinate changes when only changing heading. One thruster adorns each endcap and each side of the sub. Additionally, a strafing thruster is positioned in the center of the hull, just above the DVL. All wetplug connections conveniently interface the sub below the sub, at the DVL enclosure. Past designs have had the disadvantage of a wetplugs protruding from one endcap.


The hull has a certain added complexity from years past. Much more planning and machining goes into a design such as this one than into a tube plugged at both ends. However, given the current team of engineers, I am alright with this.

XBox meets SubjuGator

5 02 2007

Every team implements some debugging interface to their sub. You wouldn’t guess it, but there are as many ways to interface an autonomous vehicle as there are AVs in the world. Some less-developed subs require a dry, close-proximity connection. Others tow a 100+ foot ethernet cable from a wet connection on their sub. Still others build a wireless card into their vehicle. SubjuGator has traditionally used a wireless connection via a router. The router, packed into a 100% waterproof Pelican case, is connected to the sub with a wetplug connector and a length of compatible wire. I know it sounds crazy, but it’s actually very convenient to drag the case behind the sub. The hazards are minimal, and the cord allows SubjuGator to venture underwater at least a few feet (unlike subs with a built-in wireless card, which must stay at the surface to preserve the connection).

In autonomous vehicles, manual control combined with sensor feedback aids debugging more than any software IDE or hardware CAD program. The ability to note what the sensors see while the vehicle does “x” puts the developer in place of the robot’s brain and let’s him make the decisions and note their consequences. This invaluable point of view often uncovers situations that an autonmous robot’s current behaviors do not handle. For example, what happens when your ranging sonar detects a wall ahead but accumulated positioning error over time caused your navigation grid to note a mission item just behind the wall? If the arbiter assigned a higher priority to the behavior that moves the sub to the location of the mission point and a lower priority to the ranging sonar… well, you should have thought of that. Situations like these sound contrived, but I assure you they happen in real life. With manual control, a thorough testing of the interactions between behaviors, sensors, and thrusters is not only feasible, but completely viable.

After a recent developmental push, team SubjuGator can now control the sub with a standard XBox 360 controller. The new sub’s hardware is still incomplete, but the old sub uses a subset of the new sub’s sensors, boards, and computers, and so we’re able to develop software before the electrical and mechanical teams finish. Using a smooth stone and some ash from the night’s fire, I put together a crude abstraction of how an XBox 360 controller will communicate with SubjuGator.


After you’re done doting upon this extraordinary graphic, I’ll explain to you that using services (as per MS Robotics Studio) and a PC driver for XBox 360 controllers, I put together a means by which users can turn off SubjuGator’s automaticity and interface with the service that regulates the thrusters. With this capability in place, we can really begin wearing in some of the new sensors and cameras that will adorn the new SubjuGator. Plus, we’ll get a better feel for the accuracy of each sensor, what type of information they can provide, and how reliable they are overall, before we set the beast off to the wild on its own.