Not really -- the API is through method calls on to the behaviours, so
there's an interface file set up for each library. I recommend
the code that declares these primitives being in it's own file, as this is
an important piece of documentation for a behaviour library.
But Andy Kwong
ignored this. In pyPOSH the primitives are added with calls to add_sense
& add_act, and these can be found in:
pyposh/modules/[module name]/[module name].py
which is unfortunately one file with all the code for the whole
behaviour library! (Not recommended BOD style.)
Thanks, I've found it in chapter 5 [of my dissertation]. Do I understand your theory well in the following? :
"behaviours" in drive collection can subsume one another (if A is running and B just fires, then B becomes running iff prio(B) > prio(A) and A becomes interrupted. And when B finishes then A continues). Is it implemented using python threads?
But from the context of your question, I think you may mean "drive
collection elements", not "behaviours", so from here I will speak about these.
What is interrupted is the attention of the action selection mechanism So if B has higher priority than A and B's trigger condition suddenly becomes true, then A is suspended, but it's action-selection context is still held in short-term memory. If B finishes, A will be attended to again.
The thing to remember though is that B & A are both just interfaces to the behaviour objects that determine what they are doing. So while action selection is attending to B, if A was doing something that the module can do on its own (like rolling some wheels or running an anytime algorithm of some kind) then that module can keep running. It just won't receive any more external direction, and therefore probably won't be allowed to use any shared resources in the system.
If it is important to attend to A fairly often, then B can be made to only
have its high priority for some of the time. This can be done either by
clever use of internal state & the triggers, or by a built-in mechanism
which is the frequency variable in a drive element. So, for example, in a
real time system, B may be set to only receive attention 7 times a second,
or even once every few minutes. This way something that is very
important but changes only very slowly (e.g. battery level) can allow less
important things to use most of the processing time.
[Here is some more information about scheduling and interruption.]
POSH scheduling is coarse-grained parallel, where the level of granularity
is the method call to the primitive. So for example, if A is running an
action pattern {a1 a2 a3 a4}, POSH will check whether a higher-priority
drive (or competence element!) has been triggered *between* each action, but not *during* the
actions.
This is why it's a good idea to exploit the parallelism described above. You don't want a2 to take 5 minutes to run a complicated algorithm. It would be better to have a small competence that starts the algorithm, keeps checking if its done, then returns the final result if it is. This allows other important things to be checked.
Another caveat -- although a trigger is effectively a sequence, it is run atomically (all in one go). So there is an assumption that any primitive that is in a trigger must run *very* fast. I should probably enforce this with some kind of type system, but I hate strong typing![Elements] in one competence ("C" in pyPOSH) can NOT subsume one another. (if competence-element A is running then triggers of other competence-elements are not tested at all, until A finishes)
The other things is that with the slipstack, if you go into a deeper
element -- that is, if the element is itself a competence or an
action pattern, then this new element now monopolizes the drive, so in
this case your statement would be totally correct.
In the versions of POSH with an action scheduler (like pyPOSH
& the Lisp version) it's a little more complicated than that though
-- the previous element does stay on the stack for some time (set by
the parameter that you mention below!) This allows the system to
notice when a particular element's child is failing immediately, and
also makes it a little more biologically plausible. Essentially, the
older decision context stays primed for a little while.
Elements in an action pattern (sequence) are run concurrently. This means all of them are being executed in an unknown order (theoretically! unknown) and run in parallel (is it implemented using py-threads?)
Normally elements in an action pattern are run sequentially,
although there is a mechanism for saying that some of them should be
run concurrently if you want to. I assume that's what you're
talking about here. But I normally run them sequentially.
The difference in specifying which you want comes down to the number
of brackets you use.
Assuming you are trying to deliberately make the elements run in parallel, then yes, you can do this. I haven't checked Andy's implementation (I should!) I'm not sure if he did run these in parallel or not. They will all be thrown onto the action scheduler, so the real question is only whether the action scheduler will create threads for them. Hmmm... I think it should but I bet it doesn't, thinking about the original lisp code. Although I remember that Andy rethreaded the scheduler to make it run faster, so maybe he did this too. But probably the order is theoretically arbitrary, but in practice in the order coded. Again, this can easily be affected by the way that you implement your primitives -- if they start a thread they will return very quickly so it will be pretty close to parallel.
Does "parameter" (minutes 10) mean if all action pattern elements are not finished till 10 minutes, they are interrupted?
Sort of. It means that if the action scheduler finds them on the schedule more than 10 minutes after they were created, it throws them away instead of invoking them. This is another mechanism that can be used to stop a competence from looping forever, for example. But nothing goes out & interrupts calls while they are being called. (This parameter has no meaning in the non-action-scheduler versions of POSH.)
Thanks for your good questions! And deep apologies for the delay in
answering. You did the right thing to email me again, my mail spool has
gotten away from me.
page author: Joanna Bryson
back to the POSH web page