-
Notifications
You must be signed in to change notification settings - Fork 72
State Resource Example
While we hope to get a truly generic version of state resources included in EUROPA (see Possible New Features at bottom of this page), this page describes:
- How a binary resource (ie something that can be on/off) can be faked easily using the existing framework, and
- How profiles can be subclassed to get different behavior.
For a description of how we fake a binary state resource (ie a resource that can be 'on' or 'off' and has certain things that can require it to be on), see the comments in ExampleBooleanStateResourceCustomCode.hh.
A new project automatically includes its own module that is loaded into the EUROPA engine and stub C++ files to hold custom code (see [Therefore, extending EUROPA components simply requires C++ code be added to those existing files. Consider the !ExampleBooleanStateResource project here.), which can be downloaded with:
svn co http://europa-pso.googlecode.com/svn/benchmarks/tags/EUROPA-2.2/ExampleBooleanStateResource ExampleBooleanStateResource
We have added an '!ExampleConstraint' that restricts a variable to have integer bounds. To create and use the constraint involved these steps:
-
Declare and define the '!StateProfile' in ExampleBooleanStateResourceCustomCode.hh and ExampleBooleanStateResourceCustomCode.cc.
-
Register the !StateProfile. In ModuleExampleBooleanStateResource.cc:
FactoryMgr* pfm = (FactoryMgr*)engine->getComponent("ProfileFactoryMgr"); REGISTER_PROFILE(pfm, StateProfile, StateProfile);
-
Create a !StateResource class in NDDL that extends Reservoir, and, most importantly, sets 'profileType' to '!StateProfile'. In ExampleBooleanStateResource-model.nddl, notice:
class StateResource extends Reservoir { string profileType; StateResource() { super(0.0 ,0.0, 10.0); // initial, lower_limit, upper_limit profileType = "StateProfile"; } }
-
Create a class that contains the !StateResource and has predicates to turn it off and on, as well as a predicate to indicate the state is required. See ExampleBooleanStateResource-model.nddl.
-
Create an example initial state to illustrate the desired behavior. See ExampleBooleanStateResource-initial-state.nddl.
NOTES:
-
To get the desired behavior, the quantity used for 'STATE_COND_TRUE' in ExampleBooleanStateResourceCustomCode.cc must match the quantity consumed and produced by the turnOn and turnOff predicates in ExampleBooleanStateResource-model.nddl. We use 10 for each to illustrate behavior, but in practice a much bigger number should be used; it must be larger than the total number of tokens at any given time that might require the state to be on.
-
To see the results of the above example, run 'ant.' You will see the following profile, which shows: - The 'turnOn' at time 0 makes the level start at 10. - A second 'turnOn' at time 1 makes no difference. - Three 'require' tokens make the level dip below 10, while they require the state. - A 'turnOff' at time 10 makes the level drop to 0. If there was still a 'require' at this point, there would be a flaw, and the solver would fail to find a solution. - A second 'turnOff' at time 12 makes no difference. - A final 'turnOn' at time 14 sets the level back to 10.