Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I deal with symmetric property in world model #82

Open
HB-Liang opened this issue Nov 30, 2023 · 4 comments
Open

How can I deal with symmetric property in world model #82

HB-Liang opened this issue Nov 30, 2023 · 4 comments
Labels
question ROS 1 Issue affects ROS 1 ROS 2 Issue affects ROS 2

Comments

@HB-Liang
Copy link

Hi, I am using skiros2 for a simple navigation planning. I uses a connection relation that shows the connectivity between way-points and the relation should be symmetric. But in precondition check, it seems to be a directional relation.
E.g. I have a graph showing
point1 connected point2
point2 connected point3
point3 connected point1,
and with the precondition " Connected, ns:hasConnection, Start, Target, True", and point1 as Start, point3 as Target, I can get a plan that goes from point1 to point2 and point3. However, a plan that goes from point1 to point3 is also possible.
How can I check the symmetric property in condition check? Sorry for non-native expressions.
Thanks.

@matthias-mayr
Copy link
Member

You are correct that the order in relations needs to be right. This often makes sense, because ObjA onTop ObjB is not the same as ObjB onTop ObjA.

There are several ways, your use-case could be tackled:

  1. Complete the world model with relations. This is the easiest thing to do. You can write a simple python script that checks all the connections and sets the reverse connections if they are not there yet. A big plus on this is that no other modifications are needed
  2. Improved pre-condition check: There is a special condition type that can connect two conditions. The ConditionOr that can connect several conditions. Its usage is shown here. It could be used to check either relation.
  3. Extend the relation-condition check: The relation condition check could also be extended with an additional argument to check in either direction.

I am not sure how well options 2-3 go with the planner. I haven't seen anyone doing 2. and at least 3. would require coding. My recommendation would be to just complement the relations. It's the safest and easiest.

@HB-Liang
Copy link
Author

HB-Liang commented Dec 4, 2023

Thanks for your recommendations! This offers some solutions to me. I assume that the Option 1 would works well and treat it as the last choice because in my point of view, it would almost double the world model with completed relations.
I tried Option 2 in my case, using ConditionOr to combine both direction with addCondition.

self.connections = ConditionOr(True)
self.Target2Start = ConditionRelation("Connected", "ns1:hasConnection", "TargetLocation", "StartLocation", True)
self.Start2Target = ConditionRelation("Connected", "ns1:hasConnection", "StartLocation", "TargetLocation", True)
self.connections.addCondition(self.Target2Start)
self.connections.addCondition(self.Start2Target)

So far, the code seems to work well, self.connections combine both direction with "or" and I get the description as expect in the terminal:

[or] ( [Connected) TargetLocation-ns1:hasConnection-StartLocation(True) [Connected] StartLocation-ns1:hasConnection-TargetLocation(True) )

I uses self.addPreCondition(self.connections) and expects a both direction relation check. In self._pre_condition, self.connections is included.
However, when a goal was given, the generated domain file did not include the condition in self.connections, what's more, all the connection relations are not generated in problem file. Also, when I ran a single skill, the error "can't autoparametrize param" occured. Would you please give more details?
Regards.

@matthias-mayr
Copy link
Member

Thanks for your recommendations! This offers some solutions to me. I assume that the Option 1 would works well and treat it as the last choice because in my point of view, it would almost double the world model with completed relations.

I would not really worry about the extra relations, but I can see why you want to check out the other options first.

However, when a goal was given, the generated domain file did not include the condition in self.connections

That could be. I haven't taken a look at the code that translates preconditions to PDDL

what's more, all the connection relations are not generated in problem file.

That could be an effect of the missing preconditions. iirc only things that play a role end up in the problem. So if the connection is not relevant, because the nested precondition is not processed, the connection would not be in the problem file

Also, when I ran a single skill, the error "can't autoparametrize param" occured. Would you please give more details?

This typically means that some inferred connection could not be resolved. To really help you with that, it would be helpful to see the skill description and the exact error message.

@HB-Liang
Copy link
Author

HB-Liang commented Dec 8, 2023

Thank you for your patience! I finished working on Option1 with a simple changes as the addInitState function in pddlInterface would reduces duplicate state, which treated the bi-direction relation as one state.
And, when I want to use ConditionOrand run the "move" skill, I get the follow information from the X-term:
2023-12-08 09-58-04 的屏幕截图

Here is my skill description:

class TestMove(SkillDescription):
    def createDescription(self):
        #self.addParam("Turtle", Element("cora:Robot"), ParamTypes.Inferred)
        self.addParam("StartLocation", Element("skiros:Location"), ParamTypes.Inferred)
        self.addParam("TargetLocation", Element("skiros:Location"), ParamTypes.Required)
        self.addParam("Duration", 1.0, ParamTypes.Optional)
        #====PreConditions====
        self.addPreCondition(self.getRelationCond("RobotAt", "skiros:at", "Robot", "StartLocation", True))

        self.connections = ConditionOr(True)
        self.Target2Start = ConditionRelation("Connected", "ns1:hasConnection", "TargetLocation", "StartLocation", True)
        self.Start2Target = ConditionRelation("Connected", "ns1:hasConnection", "StartLocation", "TargetLocation", True)
        self.connections.addCondition(self.Target2Start)
        self.connections.addCondition(self.Start2Target)

        print(self.Target2Start.getDescription())
        print(self.Start2Target.getDescription())
        print(self.connections.getDescription())

        self.addPreCondition(self.connections)
        print(self._pre_conditions)
        #====PostConditions====
        self.addPostCondition(self.getRelationCond("NoRobotAt", "skiros:at", "Robot", "StartLocation", False))
        self.addPostCondition(self.getRelationCond("RobotAt", "skiros:at", "Robot", "TargetLocation", True))

The description was changed from turtlesim and planning example, for a simple verification that combining planning, skills, and ROS.

Update 1: During the debug process in Opition 1, the print-out information show me that I had 3 relation on skiros:at, one for cora:Robot and two for my own robot description. And after I successfully ran the first plan, my own robot changed position, presenting with skiros:at, when I want to run a second plan, I got all three skiros:at relation, one for cora:Robot and one for my own robot at the very start location, and one for my own robot at the previous target location.
Update 2: Also problem at planning process, with goal (skiros:at quadruped_description:test_quadruped ns1:TargetLocation, the generated problem file would set my robot at different class, eg. sumo:Device, or some un-regconizable.
What reason do you think that would cause this. Regards!

@matthias-mayr matthias-mayr added ROS 1 Issue affects ROS 1 ROS 2 Issue affects ROS 2 question labels Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question ROS 1 Issue affects ROS 1 ROS 2 Issue affects ROS 2
Projects
None yet
Development

No branches or pull requests

2 participants