Planner selector concept: Design and implementation questions about docs.nav2.org HOT 8 CLOSED

Is a topic subscription a good solution for the planner_selector and the goalchecker_selector?

Topic seems reasonable

Is it convenient conceptually separating planner_selector and controller_selector? Right now planner_selector aggregates the concept of (planner_selector and controller_selector)

I think so, since if we have other BT nodes like coverage planning servers, or route planning servers, that 1 node would really start to blow up. Separating them makes them more easily testable and scale as the project gets more complex.

from docs.nav2.org.

I'm happy with all of those, "Selector" name, topic names, port names. Yes, I think a default_planner_id just as the compute path to pose and follow path have would be good. That way it returns those values when none is set and the planner_id={selected_planner_id} still would enable some default behavior. From that actually, we could add that to the default BTs if you liked when these selector nodes are done (since there's still a default, just set in another location, but also then allows selections)

from docs.nav2.org.

https://github.com/ros-planning/navigation2/blob/main/nav2_behavior_tree/plugins/decorator/goal_updater_node.cpp the goal checker is very similar to what we're talking about here (topic in -> change some output port -> input port to another), this was tested and utilized in the follow_path.xml dynamic object following demos @fmrico conducted!

https://github.com/ros-planning/navigation2/blob/main/nav2_behavior_tree/plugins/action/compute_path_to_pose_action.cpp#L34 the algorithm Bt nodes use ports already for selecting IDs so using the blackboard variable ports seems like a very simple solution to the issue of conveying information between the BT nodes (that was conveyed from a topic/service via ROS2)

I think we've covered some of the other important topics here on the slack thread - any additional things we should cover as part of this?

from docs.nav2.org.

That is the correct reference example. Thanks.

• So I will introduce the following changes to the initial experiment:
  • using i/o ports instead hardcoded-propagation via blackboard
  • replacing the usage of properties with (maybe services or actions instead of topics - see below)
  • It is needed to update the FollowPath action request with a new additional field goalchecker_id

Additional issues

• Is a topic subscription a good solution for the planner_selector and the goalchecker_selector?

It may be good to respond some feedback to the requester. For example in the case the planner, controller or goalchecker is unknown or it is not registered.

• Is it convenient conceptually separating planner_selector and controller_selector? Right now planner_selector aggregates the concept of (planner_selector and controller_selector)

• An minor priority question. It is just curiosity. It looks like this is a design pattern (planner_selector, goalchecker_selector, maybe controller_selector). Shouldn't we use a template base class to let the user implement their own inputs into the nav-tree?

• Possible details of the base class:

  • c++ template parameters: TOutput (ie: std_msgs::msg::String, geometry_msgs::msg::PoseStamped), optional TInput
  • output port name string
  • optional input port name string

Maybe that is overengineering, but may be interesting to know what you think.

Regards.

from docs.nav2.org.

BTNode design
I am implementing around the planner_selector, controller_selector and goal_selector.
I am totally miming the goal_updater. That means that we will inherit:

• usage of decorator node
• configurable input topic name

Anything else to say about this?

Naming decisions
BTW, I guess it is also a good moment to also check if the naming is good. Now they are being implemented as "PlannerSelector", "ControllerSelector" and "GoalSelector".

I keep this previous plan, but:
Everything okay with that? Maybe PlannerSwitcher? PlannerConfiguration?

Also the name of the output ports. Right now:

• selected_planner
• selected_controller
• selected_goal_checker

Finally about names of the topic names

• /planner_selector
• /controller_selector
• /goal_checker_selector

what about them?

Default values feature
One last thing. For the initial case when not any topic message was received. We have the option of setting a default planner/controller/goal_checker name as a "static-value input port". Should that functionality be there?
if not the alternatives would be:

• access to the parameter server to get the default values for planner/controller/goal_checker
• or providing empty outputs

from docs.nav2.org.

I created an initial PR for the planner_selector before applying PRs for others (controller_selector and goal_checker_selector)

ros-navigation/navigation2#2249

from docs.nav2.org.

Closing, see Nav2 ticket / PR set

from docs.nav2.org.

Any one can share a xml configure that works for galactic version? I setted as below, it's not working!!!

<root main_tree_to_execute="MainTree">
    <BehaviorTree ID="MainTree">
        <RecoveryNode number_of_retries="6" name="NavigateRecovery">
            <PlannerSelector selected_planner="{selected_planner}" default_planner="GridBased"
                             topic_name="planner_selector">
                <PipelineSequence name="NavigateWithReplanning">
                    <RateController hz="1.0">
                        <RecoveryNode number_of_retries="1" name="ComputePathToPose">
                            <ComputePathToPose goal="{goal}" path="{path}"/>
                            <ReactiveFallback name="ComputePathToPoseRecoveryFallback">
                                <GoalUpdated/>
                                <ClearEntireCostmap name="ClearGlobalCostmap-Context"
                                                    service_name="global_costmap/clear_entirely_global_costmap"/>
                            </ReactiveFallback>
                        </RecoveryNode>
                    </RateController>
                    <RecoveryNode number_of_retries="1" name="FollowPath">
                        <FollowPath path="{path}" controller_id="FollowPath"/>
                        <ReactiveFallback name="FollowPathRecoveryFallback">
                            <GoalUpdated/>
                            <ClearEntireCostmap name="ClearLocalCostmap-Context"
                                                service_name="local_costmap/clear_entirely_local_costmap"/>
                        </ReactiveFallback>
                    </RecoveryNode>
                </PipelineSequence>
            </PlannerSelector>
            <ReactiveFallback name="RecoveryFallback">
                <GoalUpdated/>
                <RoundRobin name="RecoveryActions">
                    <Sequence name="ClearingActions">
                        <ClearEntireCostmap name="ClearLocalCostmap-Subtree"
                                            service_name="local_costmap/clear_entirely_local_costmap"/>
                        <ClearEntireCostmap name="ClearGlobalCostmap-Subtree"
                                            service_name="global_costmap/clear_entirely_global_costmap"/>
                    </Sequence>
                    <Spin spin_dist="1.57"/>
                    <Wait wait_duration="5"/>
                    <BackUp backup_dist="0.15" backup_speed="0.025"/>
                </RoundRobin>
            </ReactiveFallback>
        </RecoveryNode>
    </BehaviorTree>
</root>

Log of bt_navigator show immediately succucess!!!

from docs.nav2.org.