Arbiter 1.0

9 03 2007

arbiter11.gif

 

 

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.