Multiple classes of Designators

Since a typical template of a Designator looks like one of the following:

(an action (type trajectory) ( ... ... ) ( ... ... ))

(an object (type cup) ( ... ... ) ( ... ... ))

(a location (type ... ) ( ... ... ) ( ... ... ))

(a designator-template (type designator-type) ( ... ... ) ( ... ... ))

We can resolve all those types of Designators via Prolog. Why do we wrap those key-value pairs in another LISP type and give up on resolving them via Prolog and instead use more complicated code to resolve them?

@moesenle @fairlight1337 @airballking @yazdani @bbrieber @mpomarlan @gaya-

[fairlight1337]

I would say this gives additional meta information about the designator itself, and how it is processed in the system.

Lots of the "control data", such as the last generated pose from location designators, the successor/parent relationships, and the unique object IDs in designators are not part of its "payload data" (i.e., its description). These two very different information sets shouldn't be intermixed, as information from one could easily overwrite the over.

Is there a strong motivation of doing it in a different way from what we are doing right now? With the current approach, we can make use of Common Lisp language features that distinguish between different classes (object-, location-, action-designator).

[airballking]

@gheorghelisca isn't this the same issue as #30 which you just opened?

@airballking They are somehow related. If we agree on using only Prolog and no LISP class dispatcher for resolving designators #30 then we can use any types of Designators we want. There is no constraint to define new classes of Designators. The designator will talk about it's class by itself.

[gaya-]

Actually, the examples that you gave are not how we represent designators at the moment.
It's not
(an action (type trajectory) ( ... ... ) ( ... ... ))
but
((type trajectory) ( ... ... ) ( ... ... ))
I know that Michael would prefer the first representation.

To be honest, I always found that dividing things that you can represent in a robot plan into only 3 categories a bit too restrictive, and having action designators resolve into trajectories or robot arm names or grasp configurations etc. also not so straightforward (how is a :robot-left-arm an action?, at least call it an action-property-designator). Now that Georg will have human tracking information that he would also like to describe within a designator (did I understand that correctly?) this kind of 3 categories restriction seems to be uncomfortable.

I would be in favour of getting rid of this restriction. Then we could, in fact, use Prolog to dispatch to different resolving mechanisms. The designator class will then contain a label slot, which will define where to dispatch. E.g. we will be able to write:

(a trajectory (arm :robot-left-arm) (constraints georgs-constraint-description))
(a grasp (arm left) (object cup))
(an action (to cook) (object sandwich))
(a path (from A) (to B))
(an object (type ...))
(an actor (type human) (name ...))
(an actor (type robot) (name boxy))
(a location (...)
(a behaviour (...)
The label will then be: action, grasp, object, actor, location, ...
Prolog will then decide, based on the label, which mechanism to apply to resolve the designator.
However, we don't want to have all the resolving mechanisms, including human perception and making pizza, running, if we only want a tiny demo of the robot picking and placing one cup on one single table. We want to keep the system as modular as possible. For that, each resolving mechanism would have to register itself in Prolog and Prolog should be able to know which mechanisms are available at the moment to be used for resolving etc. That will become pretty similar to the location costmap mechanism that we have now when you use different location designator resolution mechanisms depending on which Lisp modules you have loaded. That mechanism is extremely hard to debug, the people who worked with costmaps will probably agree with me: it is really hard to know which resolution mechanism is being used and which is not etc. This mostly comes from our Prolog implementation which is very limited and I'll just say weak.

Bottom line: in my humble opinion, Gheorghe's proposed change would be nice:

+ it will give us more expressive power in terms of writing our plans

• it might make the designator resolution mechanism a bit more universal and easier to understand.

But, because our Prolog interpreter is so limited and weak

- it will make the resolving mechanism even less transparent and hard to debug.

It is already really hard to debug designator resolution, especially when it comes to locations, making it even harder will be a disaster. So, I'd say, before we can get started with this issue, we should concentrate on improving our Prolog interpreter first (or considering other options like using SWI Prolog).

@gaya- It's not necessarily to decide on the label. Prolog is able to "understand designator's description" and further reason on it.

If we don't want to have all resolving mechanisms, then we just don't load them. We only load what we need for the small demo.

CRAM shouldn't be bound to use Prolog implementation in LISP. It should consider the benefits of using a native implementation of Prolog (clean syntax, etc.). It should have the alternative to perform the reasoning task on a real SWI-Prolog without being constraint to give up on LISP implementation of Prolog.