2

I am using Eclipse (version: Kepler Service Release 1) with Prolog Development Tool (PDT) plug-in for Prolog development in Eclipse. Used these installation instructions: http://sewiki.iai.uni-bonn.de/research/pdt/docs/v0.x/download.

I am working with Multi-Agent IndiGolog (MIndiGolog) 0 (the preliminary prolog version of MIndiGolog). Downloaded from here: http://www.rfk.id.au/ramblings/research/thesis/. I want to use MIndiGolog because it represents time and duration of actions very nicely (I want to do temporal planning), and it supports planning for multiple agents (including concurrency).

MIndiGolog is a high-level programming language based on situation calculus. Everything in the language is exactly according to situation calculus. This however does not fit with the project I'm working on.

This other high-level programming language, Incremental Deterministic (Con)Golog (IndiGolog) (Download from here: http://sourceforge.net/p/indigolog/code/ci/master/tree/) (also made with Prolog), is also (loosly) based on situation calculus, but uses fluents in a very different way. It makes use of causes_val-predicates to denote which action changes which fluent in what way, and it does not include the situation in the fluent!

However, this is what the rest of the team actually wants. I need to rewrite MIndiGolog so that it is still an offline planner, with the nice representation of time and duration of actions, but with the causes_val predicate of IndiGolog to change the values of the fluents.

I find this extremely hard to do, as my knowledge in Prolog and of situation calculus only covers the basics, but they see me as the expert. I feel like I'm in over my head and could use all the help and/or advice I can get.

I already removed the situations from my fluents, made a planning domain with causes_val predicates, and tried to add IndiGolog code into MIndiGolog. But with no luck. Running the planner just returns "false." And I can make little sense of the trace, even when I use the GUI-tracer version of the SWI-Prolog debugger or when I try to place spy points as strategically as possible.

Thanks in advance,

Best, PJ

false
  • 10,264
  • 13
  • 101
  • 209
PJvG
  • 1,310
  • 3
  • 16
  • 33
  • Indeed, a daunting task ! My compliments, and I wish you all the best of luck. – CapelliC Oct 18 '13 at 16:21
  • 2
    I fear the GUI tracer make little sense, maybe you're going better with `?-leash([-all]),trace.` and then enter an *extremely* simple query you know should succeed. You will have chance to examine the execution sequence and see where it fail. – CapelliC Oct 18 '13 at 16:27
  • 1
    I wonder why you're departing from Mozart ? – CapelliC Oct 18 '13 at 16:31
  • Thanks. I did not know about leash yet, I'll try that after the weekend. I'm using the Prolog version of MIndiGolog instead of Mozart, because, in the project I'm working on, the planner needs to communicate with an execution layer made in Python. We already have an interface between Prolog and Python, we do not have an interface between Mozart and Python. – PJvG Oct 20 '13 at 11:28
  • The leash-thing is not that much more help than a normal trace imo, but it is a nice feature nonetheless. After discussing some more with my team, we decided it is best to focus on other issues and rethink if we really need that causes_val-predicate of IndiGolog. – PJvG Oct 23 '13 at 14:07

1 Answers1

1

If you are still interested (sounds like you might not be): this isn't actually very hard.

If you look at Reiter's book, you will find that causes_vals are just effect axioms, while the fluents that mention the situation are usually successor-state-axioms. There is a deterministic way to convert from the former to the latter, and the correct interpretation of the causes_vals is done in the implementation of regression. This is always the same, and you can just copy that part of Prolog code from indiGolog to your flavor.

Christian Fritz
  • 20,641
  • 3
  • 42
  • 71
  • Thanks for the answer, but you're right I am not really interested in it anymore. We made different design choices now and I won't check (for now) if I can solve my problem now with your advice. (Maybe I'll come back to it later, but I doubt it..) – PJvG Dec 19 '13 at 09:07