Arbiter 1.0

9 03 2007




The above image is our proposed design for the Arbiter service, pictured as a mere box in past diagrams. The Arbiter will comprise many services, some that have not been hashed out yet, such as those within the box labeled, “Decision Broker.”

The yellow box containing behaviors 1..N represents a set of services that that direct the behavior of SubjuGator. These behaviors range from specific mission tasks– locating the acoustic pinger, following the pipe, bumpins buoys– to mission daemons that ensure SubjuGator doesn’t do anything stupid like run into a wall or plunge to the bottom of the TRANSDEC. One behavior at a time will control NavActions. The double-ended arrow means that the controlling behavior and NavActions will subscribe to each other. Upon a behavior change, NavActions will be unaware which is the new behavior. Therefore, it makes sense that the new bahvior would send a ‘hello’ message to NavActions, who would respond with a ‘welcome.’

The decision broker, seen from up high here as a large blue box, interfaces the behaviors. Certain behaviors run all the time alongside mission behaviors, while others run in mutual exclusion. The service(s) that form the decision broker entity will handle the intelligence for managing, (de)activating, and switching behaviors.

The decision broker and any behavior pass a standard object between themselves for communication. That object contains a few simple data members: speed, heading, priority, confidence, classification, state, and presence vector.

  • Speed & Heading:  When the object travels from the behavior to the decision broker, speed and heading denote the values set by the behavior; from the other direction, they mean the actual values as recorded by sensors.
  • Priority:  Priority is the precedence a behavior takes over others. A behavior may not change its own priority. This data member travels one way only, from the decision broker to the behavior.
  • Confidence:  Confidence is a measure of the certainty that a task has encountered, or locked onto, its mission task interest. The subject of a behaviors confidence differs between behaviors. This data member, like prioity, travels one-way from the decision broker to the behavior.
  • Classification:  Classification describes the type of behavior– whether it is mutually exclusive to other behaviors, mandatory, etc. This static data member travels only from the behavior to the decision broker.
  • State:  Like confidence, what this value represents will vary widely between behaviors. Generally, it describes the progress/status of a behavior.
  • Presence vector: This data member notes which of the above data members are included in each message between the behaviors and the decision broker.

Step back and focus

8 03 2007

Sometimes it’s too easy to sit back and throw out ideas about clever innovations that could make the sub more intelligent, easier to debug, more modular, etc. There comes a point, however, when the design must be finalized so that implmentation may continue (or begin). This jump from design to implementation is difficult to make, and it is even more difficult to schedule that jump.

Ideas will pour from our minds until they cease to operate. However, with the competition only four months away, the time for design-altering ideas has passed. Our limited development team with limited time, due to classwork, research, and various other commitments, must now focus on completing the base system. This is not to say that we do not have expansion in mind– we can plan for these by creating an open-ended base system (MS RoboStudio helps tremendously here), but the implementation of fancy intelligence algorithms and sharp GUIs must wait.

A word of advice to others undertaking large robotics projects: Don’t lose sight of the main goal. Take a step back every once in a while to analyze your situation and your progress, and set yourself on track if necessary.

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.