Incompatibility with Nav2 BT nodes

[ajtudela]

Hi,
I'm currently integrating PlanSys2 with Nav2 and I've encountered a compatibility issue related to Behavior Tree (BT) nodes.

Specifically, I'm trying to reuse existing BT nodes provided by Nav2 (such as NavigateToPose, IsBatteryLow, etc.) inside PlanSys2 actions. However, these nodes expect certain variables to be present in the blackboard (like bt_loop_duration, etc.). Since PlanSys2 does not automatically populate these keys, the nodes fail at runtime due to missing or uninitialized blackboard entries.

This creates a barrier to reuse, forcing developers to either:

• Reimplement the BT nodes to fit PlanSys2's structure, or
• Add workarounds that inject the necessary variables into the blackboard manually.

Would it be possible to consider improving interoperability between PlanSys2 and Nav2?

[roveri-marco]

Hi Alberto,

Before extending plansys2, we need to understand the roles of those variables and who is expected to populate them (i.e., Is it specific to the action? Is it a general constraint? Does it depend on the robot?, ...).

From an architectural point of view, it would be good to create a node NAV2, that can be launched together with PlanSys2 and contain what is needed. Of course, it would be important to understand the position of @fmrico.

Moreover, I have a doubt. Since navigation seems to implement a GOTO x,y action (or similar), then from my point of view, it is the action's responsibility to create what is needed to create the BT NavigateToPose and not PlanSys2. Indeed, the action implementation is not part of plansys2, and one can implement an action as he/she likes (given the interface expected by PlanSys2).

[ajtudela]

In Nav2, it's the BehaviorTree engine the responsable of creating and populating those keys into the blackboard. Some of the keys are related to timeouts for the action client and loop duration. PlanSys2 could probably benefit from having those keys/parameters too.

I don't think it's necessary to create new nodes; we just need to adapt what we have in PlanSys2 (or Nav2) to find a middle ground where both systems can coexist.

Nav2 has more BT nodes than NavToPose or NavThroughPoses that, I think, could be use with PlanSys2, nodes like Spin, IsBatteryCharging, IsBatteryLow, etc.

[roveri-marco]

Hi Alberto,
I know that there are nodes in Nav2 that could be used in PlanSys2. For instance, suppose in the PDDL model there is a predicate (battery_charging r1) or (battery_low r1), and these predicates appear as a precondition or effect of an action; Currently, while executing the plan, each predicate is checked/enforced in the knowledge base, depending whether it is a precondition or effect. However, no semantic attachment to proper sensors is currently implemented. It would be desirable to attach the evaluation of each predicate to the respective sensor node (similarly to actions) that, in turn, may use Nav2 nodes, or use the sensors to update the knowledge base from sensors periodically. As far as I know, this behaviour is not yet possible in PlanSys2.

Moreover, there might be different robots, each with different needs for different nav2 parameters.

Fianlly, it will create a strong dependency on nav2 (I'm not against, but we need to agree on this dependency then).

[ajtudela]

Hi Alberto, I know that there are nodes in Nav2 that could be used in PlanSys2. For instance, suppose in the PDDL model there is a predicate (battery_charging r1) or (battery_low r1), and these predicates appear as a precondition or effect of an action; Currently, while executing the plan, each predicate is checked/enforced in the knowledge base, depending whether it is a precondition or effect. However, no semantic attachment to proper sensors is currently implemented. It would be desirable to attach the evaluation of each predicate to the respective sensor node (similarly to actions) that, in turn, may use Nav2 nodes, or use the sensors to update the knowledge base from sensors periodically. As far as I know, this behaviour is not yet possible in PlanSys2.

Thanks for that information. I wasn't exactly sure how the preconditions/effects were checked against the robot's sensors. I can work on that feature if that's OK.

Fianlly, it will create a strong dependency on nav2 (I'm not against, but we need to agree on this dependency then).

I don't think it would create any dependency at all because the parameters relate to ROS/BT and not Nav2.