Here - Agents Lab - University of Nottingham

component plans have been instantiated for a specific robot agent, i.e. Turtle-Bot, the services they provide will have an Agent attribute with value TurtleBot.However, in order for the same services to work, they must receive updates, respectively,of location and video data related to the same robot agent. BothXML descriptions specify this dependency by repeating the attribute ?Agent inthe reference elements describing their required service goals. It is the responsibilityof Self -OSGi to propagate the value of these variable properties fromthe post-condition/service side to the requirement/reference side, for instance,to wire a Navigator component activated in the TurtleBot robot agent, with aLaserLocalization activated for the same robot agent, rather than using the puresyntactic match (which could be satisfied by any localization data, e.g. relatedto other robots or used to represent the location of a human user).3.3 Core Implementation:The interested reader is refered to Dragone [3], for more detailed information onthe internal architecture of each Self -OSGi platform.The main difference from traditional agent platforms, such as the Agent Factory(AF) platform developed in UCD [18], is that agent container functionalitiesare built directly over the OSGi bundle and component container. In addition,rather than employing logic-based agent languages, Self -OSGi’s goals and plansare directly specified in Java, as discussed in the previous sections.As a way of example, the following code is used to send a robot to a givenlocation by initializing a standard OSGi ServiceTracker object to request theGoalNavigation service goal, before invoking it by passing the location coordinates.The special attribute selfosgi=true is used to demand the Self -OSGimanagement of the call. Noticeably, no other modifications are required to standardOSGi programming.ServiceTracker tracker = new ServiceTracker(...,context.createFilter("(\&(objectClass="+GoalNavigation.class.getName()+") (selfosgi=true)").open();(GoalNavigation)(tracker.waitForService(0)).beAt (100, 200);The service goal request is intercepted by Self -OSGi, which queries the OSGiDS for the list of all the components able to provide the requested service (i.e.LaserLocalization and CameraLocalization in the example). After that, Self -OSGi implements the BDI cycle by (i) finding all the component plans (installedin the same OSGi platform) with satisfied pre-conditions (i.e. which hold againstthe current content of the belief set), and (ii) instantiating (loading) and activatingthe most suitable one by using user-provided ranking components. Finally,Self -OSGi installs a proxy between the client that has originally requested aservice goal, and the component activated to provide it. It is thanks to this mediation,that Self -OSGi can catch failures in the instantiated services activation,and trigger the selection of alternative component plans.In the localization example, these features are used to make the robot reachits destination while opportunistically exploiting any suitable localization mechanism,for instance, starting with the CameraLocalization and then switching to77