Skip to content

Plan-repair (3/3): goal_manager_node with private topics and abstracted flow#29

Open
JY-HIM4U wants to merge 2 commits into
feature/omniplanner-repair-nodefrom
feature/goal-manager-node
Open

Plan-repair (3/3): goal_manager_node with private topics and abstracted flow#29
JY-HIM4U wants to merge 2 commits into
feature/omniplanner-repair-nodefrom
feature/goal-manager-node

Conversation

@JY-HIM4U
Copy link
Copy Markdown
Contributor

goal_manager improvements:

  • Private topics (~/commanded_goal, ~/planner_goal, ~/plan_visited_pois, ~/executor_pause, ~/executor_resume).

  • commanded_goal_cb structured as pause -> decide -> resume_or_replan -> log; the domain-specific "is the new goal already covered" check is isolated in _goal_already_satisfied, making the extension points visible.

    • PR 1: planning-side constraint plumbing (ConstraintFact, ConstrainedPddlGoalMsg, PddlGoal.constraints, grounding-level filtering).
    • PR 2: ROS-level repair node + plugin + plan-info publishing hook.
    • PR 3 (this): goal_manager_node that consumes the visited-POI topic and decides resume-vs-replan.

…ed flow

goal_manager improvements:
- Private topics (~/commanded_goal, ~/planner_goal, ~/plan_visited_pois,
  ~/executor_pause, ~/executor_resume). Concrete wiring is done by
  roslaunch remap, not by ROS parameters.
- commanded_goal_cb structured as pause -> decide -> resume_or_replan -> log;
  the domain-specific "is the new goal already covered" check is isolated
  in _goal_already_satisfied, making the extension points visible.
Copy link
Copy Markdown
Collaborator

@GoldenZephyr GoldenZephyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reasonable overall, but see my comment about extracting information from the goal string.

_VISIT_PREDICATE_RE = re.compile(r"\(visited-(?:place|object|poi)\s+([^\s\)]+)\)")


def extract_visit_targets(pddl_goal: str) -> Set[str]:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that this function is being used to detect which places the plan needs to visit, to check if we need to replan. I don't think this regex is sufficient for that. There are two problems: 1) The goal string might have something like (not (visited-place p1)) , so p1 is in the goal string but shouldn't be considered a place we want to visit, 2) The goal can have disjunctions, so if we have (or (visited p1) (visited p2)) we can't assume that both p1 and p2 should be visited. The goal string is a nested tree structure so we shouldn't expect to be able to parse it with a regular expression.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing out this issue. I edited!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants