Resolving all Designators via Prolog

[gheorghelisca]

I was wondering why we don't use Prolog to resolve all Designators? At the moment only Action Designators are resolved based on Prolog, the rest of Designators are resolved based on their type. Since the "Designator" concept implies a list of key-value pairs I see Prolog the perfect candidate to look at this list and call the right function for it.

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

[fairlight1337]

What do you mean, by their type? Location designators, for example, are resolved based on the costmap predicates all over CRAM (see, for example, location_costmap).

So, we're actually doing that already. Or did you mean something different?

[airballking]

I think Gheorghe refers to the fact that the designator protocoll declares resolve-designator and reference using defgeneric. Meaning: The Common LISP class dispatcher will call the correct implementation based on the type of the designator at-hand:

https://github.com/cram-code/cram_core/blob/master/cram_designators/src/cram-designators/designator-protocol.lisp#L93

https://github.com/cram-code/cram_core/blob/master/cram_designators/src/cram-designators/designator-protocol.lisp#L106

However, resolve-designator of action designators actually directly calls prolog, and resolve-designator of location designators use the costmap functions which internally use prolog to perform the nots and bolts of resolving the ambiguity.

I interpret Gheorghe's question like this: How about having one function resolve-designator which just calls prolog to resolve the description of the designator?

[fairlight1337]

Would this be resolved by just adding one function with this name that calls the respective current implementation, based on the designator class?

If its just a convenience issue, this should be easy.

[gheorghelisca]

Yes, Georg explained it right. I think it's more elegant to resolve designators via only their content rather than both their type and their content.

I mean that instead of letting LISP to look at the location type via inheritance and calling the location_costmap map, Prolog could look at designator's contend and call the location_costmap directly.

[gaya-]

I agree that designators lack a uniform protocol of resolving them and that is confusing. However, the 3 types of designators that we have right now are very different entities:

• object designators, e.g. ((type cup) (color red)) can only be resolved using the perception mechanisms,
• location-designators need geometric information about the world to be resolved, they also might need the occupancy grid of the environment, working localization of the robot, etc. (Please note, that location designators are not necessarily resolved using costmaps, costmaps are not the only mechanism for resolving location designators.)
• action designators can return very different things, sometimes it can simply be a grasp that the robot should apply. E.g. ((type grasp) (object cup)) can return a list (left right) to describe which arms can possibly grasp a cup, as opposed to ((type grasp) (object pot)) which would return (both), which means you need both arms to grasp a heavy pot. This type of resolving a designator is simply a collection of rules, that is why we use prolog here to implement these simple rules. Those rules are, e.g., "if the object is a cup, grasp it with any of the hands".

In general, Prolog is not necessary for resolving designators at all, using it will only add more overhead to the already complex mechanism of resolving designators, as it will still call Lisp under the hood. However, if you can think of an elegant way of unifying the designator resolution mechanism using Prolog in a straightforward way, the efficiency overhead might be worth it. I, personally, don't see right now a way of elegantly unifying the designator resolution mechanism using Prolog.

[gheorghelisca]

@gaya- We all know those details - all of them can be part of designator's key-value list and there is no need to additionally overload this list with a new type (the type of designator). Designator's collection of key-value pairs is enough to talk about the designator itself.

I find Prolog very elegant to resolve designators simply because of Designators structure: key-value pairs. Further more I think it's an elegant alternative the the complex mechanism (based on LISP's inheritance) we're running right now. To me it feels like designators were build for Prolog.

"What functionality Prolog calls when it matches a designator?", it's another question. It can call perception, location_costmap, projection, even other subplans.

My point is that we don't need to use LISP type system and a complicated mechanism to resolve desginators or at least we don't need to simultaneously use both Prolog and LISP type system to call the functionality described by a designator. It's list of key-value pairs it's enough.

[gheorghelisca]

@fairlight1337 I am afraid it's a bit more complicated and would trigger fundamental changes, hence I am opening this discussion to see if it's worth.