Proposed approach
To achieve the maximum reliability and flexibility in the platform, two conditions are needed. First behaviors have to be independent of one another; and second, behaviors have to be able to switched on and off depending on the current task or goal. The independency requirement helps in the situation where a behavior fails for whatever reason or, if it is simply not needed anymore, can be deactivated. The general idea is to break up an agent into three abstract parts; sensors, behaviors and effectors. Sensors measure variables in the environment and have them available to behaviors. Behaviors process the variables from the sensors and produce a value that is passed to the effectors. The effectors control the parameters that affect the environment. This can be the speed of an engine or the wheel in a car. Diagram 1 shows the relationship between the different interfaces in an agent.
In a BBS all components are asynchronous. That means that sensors, behaviors and effectors are all performing their functions at different rates. The connection between sensors and behaviors doesn't produce problems because the sensors just grab the most current value that the sensors have whenever they need it. The problem arises when behaviors interact with the effector. A solution is to have the behaviors cast votes into the effectors when they have finished processing their inputs. Each vote contains a proposed change of the value in the effector.
Diagram 1. Player-stage simulation showing the boat tracking the buoys.
The solution proposed in [1] is similar to this one but doesn't address the following problems. The first problem is that faster behaviors can bias the effector's decision because they can vote more times in a given period of time. The second problem is that a slow behavior that has a rate lower than that of the effector can only participate in the process sporadically, giving an advantage to faster behaviors. The solution is to include along with the vote, a value that indicates for how long the vote will remain valid. The effector will keep the vote for the specified lifetime and use it to generate an output. The result is that votes with longer lifetimes can influence for longer periods.
Behaviors can produce conflicting decisions. One way to solve this situation is to have the most relevant behavior (in terms of the current goal) enabled and those that conflict with it disabled. This however, can make the agent behave erratically when it transitions between behavior states. Another drawback is that there would have to be a separate module that controls these states, reducing the robustness of the system and eliminating the possibility of satisfying multiple sub-goals. The solution is for behaviors to include in the vote a priority level that represents how critical is to the agent the change that the behavior is proposing. This way a proposition from obstacle avoidance will have more weight than one from wandering yet both will influence the output.
It is up to the effector to fuse the votes into one change. As it has been mentioned already, votes have in addition to the proposed change value, a lifetime value and priority level. The equation used by the effector is shown below.
(1)
The summation is done over all the votes. x is the proposed value contained in a vote, p is the priority level. There are two special cases for the votes: 0-priority and maximum-priority. A 0-priority vote will not count if there is a non-zero priority vote in the list. This is useful for behaviors that only need to be taken into account when there is not anything else to do, like wandering. If there are one or more votes with a maximum-priority, the latest one to arrive will be the only one to be considered by the effector. In an emergency situation, a behavior can increase its own priority momentarily to control the output while the emergency lasts. This adds to the system flexibility.