|Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.|
CogniTAO (BDI)Description: BDI Intro
Tutorial Level: INTERMEDIATE
Next Tutorial: decision_making/Tutorials/CogniTAO(C++)
The goal of CogniTAO is to let programmers build and simulate entities that can execute complex missions in dynamic environments, where it is impossible to foresee all possible decisions. It is a high-level control component which utilizes modern robotics control paradigms to allow coordination between multiple robots working in teams, tight coupling between the decision-making and the world modeling components, while mixing goal-oriented and reactive control, all according to the principals of BDI.
CogniTAO is built to be truly plug-and-play: It is developed to be platform-neutral, and is capable of interfacing robot platforms of all types, shapes, and sizes (UGVs and UAVs, Aldebaran Nao robots, research platforms such as Mobile Robots Pioneer, and many more).
the behavior is grouped, the agent is actually the whole team.
"Think of it, as Team Oriented Programming..." (Dan Erusalimchik, Head programmer and Architect for CogniTAO)
The CogniTAO flow-chart and heirarchy graph are the basic user-designed building stones, and are described as below:
Defines the current Task to be performed, contains Start and End Conditions, and is coupled with corresponding Plans through "Allocation" protocols and "Next" protocols.
All the Plans on the same level start together, and actually create:
- A mutual agreement about Starting synchronization.
- A mutual agreement about Ending synchronization.
- A mutual agreement about Entity roles in a program.
A TAO is a level of a number of Plans and their corresponding "Sons", "Allocations", and "Next" protocols.
The "Next" Protocol takes place when a current plan ends, and essentially chooses one next plan to be performed. It has the possibility to loop it's own plan (i.e. 'return' back and re-run the plan, see TAO(Increment) Task), and can be a user-designed protocol.
The Allocation Protocol takes place in a running plan, and essentially chooses (or divides) a sub plan, that will be performed. It DOES NOT have the possibility to loop the given plan node, and the chosen plan can be allocated using a user-designed "Allocation" protocol.
Notice: if child of an Allocation Protocol 'die' (i.e. child can not continue to his own "Next" protocol) then the father 'dies'.
Start and End Conditions
Boolean conditions defined inside each "Task". Start conditions are validated before the plan is selected for running, and Stop conditions are validated through out the whole running time of the plan.
The overall hierarchy structure is synchronized in a system that utilizes multiple entities, so team work will correspond to the same "Next" protocol, and "Allocation" will divide sub-groups to same corresponding "Next" protocols respectively. The big picture is as follows:
We'll use our rqt_decision_graph to demonstrate the components metioned above:
Notice the Strat\End conditions, Allocation and Next protocols, and father-son heirarchy.
The basics about BDI