12 December 2004

Q & A about POSH (especially pyPOSH)

Questions are from Cyril Brom, of Charles University in Prague.

Does any documentation for pyPOSH API agent(behaviour)--world interface exist? I've missed in it the thesis (maybe I've simply overlooked at...).

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?

"Behaviours" in BOD are code modules which support a number of primitives for both sensing and acting. See the discussion in chapter 1 & 2 of the dissertation. You can implement those with threads if you like, since they are meant to be able to run in parallel (but I don't generally bother to do this...)

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)

There are two things different about a competence.  First, if a higher priority step / element takes over, then unlike the drive collection no information is maintained about what had been being done at the lower competence element level.  The assumption is that if a higher priority element has been triggered, the plan has progressed.  Since it is a reactive plan, it can still regress if necessary, but then the lower priority element will start over from scratch.

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