23.08.2015 Views

Here - Agents Lab - University of Nottingham

Here - Agents Lab - University of Nottingham

Here - Agents Lab - University of Nottingham

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Specifically, the PEIS tuplespace is used to:1. serve as platform discovery mechanism, by leveraging its peer-to-peer communicationfunctionalities to re-create on each platform the directory <strong>of</strong> allthe platforms available over the network. Self -OSGi uses these directories t<strong>of</strong>ind out the url <strong>of</strong> remote instances <strong>of</strong> Self -OSGi, before using R-OSGi tocontact them by sending service goal requests and conducting auction-basednegotiation protocols.2. communicate with the PEIS-Init components installed on each platform, inorder to manage PEIS components running outside the JVM, such as roboticbehaviour components implemented in native C/C++ languages. In thesecases, component plans in Self -OSGi acts as proxies <strong>of</strong> the underlying PEIScomponent they manage. A basic implementation - PEIS Component Monitor- provides generic functionalities to start/stop/configure peis componentsby setting the value <strong>of</strong> special tuples used to propagate these instructionsvia the tuplespace.5 Testing Tools and ExampleFor the purpose <strong>of</strong> testing and demonstrating the overall implementation <strong>of</strong> themulti-agent framework presented in this paper, we have developed a set <strong>of</strong> PEIStools capable <strong>of</strong> simulating the sensing and actuation aspects <strong>of</strong> components,while running the full framework for specification, introspection, deployment,communication and configuration. These tools are intended to simplify the developmentand debugging <strong>of</strong> the agent based tools and their interaction with therobotic ecology, and facilitate their adoption in real world situations.The test illustrated in this section shows the ability <strong>of</strong> our framework toautomatically generate a sequence <strong>of</strong> configurations to perform a given task in thecurrent context (state). The test has been performed in a low-fidelity simulatoremulating the behaviour <strong>of</strong> real devices distributed over three platforms:1. a robot (robot-1 ) equipped with a laser ranging sensor, an odometry sensors,and a navigation component plan.2. a robot (robot-2 ) equipped with a 3D ranging camera, an odometry sensors,a navigation and a tracking component plan.3. a server (server) with an installation <strong>of</strong> a simultaneous localization andmapping (SLAM) component plan.Scenario: In order to drive the robots, both navigation component plansmust rely on odometry and localization information (their service goal requirement).However, none <strong>of</strong> the robot platforms have enough computational powerto run a localization component plan locally. Fortunately, an instance <strong>of</strong> theSLAM component plan - running on the server - can provide location updates,as long as it receives data from both one ranging sensor and from the odometry<strong>of</strong> the robot. In addition, robot-2 can use its 3D ranging camera to observe the80

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!