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.

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.

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.

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.

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 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.

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.

Last year, SubjuGator operated around (and it really kills me to mention this to anyone) just one loop with just one thread. Multi-threading, in my opinion, buries most autonomous robots before they have a chance to explore their surroundings. Like a driver on a cellphone with a coffee in hand, threads don’t always work nicely together, and they may not appear to disrupt each other until your autonomous sub ramming the bottom of the swimming pool. Threads are also more difficult to debug in a not-quite-built autonomous robot– you can’t test the thruster threads with the camera threads until those items have been added. It’s a poor excuse, but one loop was easier to conceptualize, develop, debug, and test. Drawing information from sensors was a serialized task and efficient sensor fusion was near impossible.

With the dawn of Microsoft Robotics Studio, all this is changed. The best thing Microsoft brought to the table with Robotics Studio was a way to gain all the benefits of multithreading without all the hassle. In defining services, protocols for communication bewteen the services, and background processes to host the services, Robotics Studio makes multithreading inherent in a software system. Sensor fusion now occurs as a service that subscribes to two or more other services that distribute sensor data or represent some source of information. The  multithreaded, event-driven nature of Robotics Studio eliminates the loop and offers a viable way to intepret and analyze data from multiple sensors.

Other secondary services have also been discussed. One of the most notable has already been implemented– a simple manual control of the sub’s movement via an XBox 360 controller. Also, since logging mission data (images taken by the cameras, decision made by the arbiter, etc) has always helped us at past competitions, a logging service will be implemented.