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

condition distance traveled always returns failure #4842

Open
guidout opened this issue Jan 10, 2025 · 4 comments
Open

condition distance traveled always returns failure #4842

guidout opened this issue Jan 10, 2025 · 4 comments
Labels
question Further information is requested

Comments

@guidout
Copy link

guidout commented Jan 10, 2025

Since when the behavior tree is first loaded, all nodes are in the IDLE state before they are ticked for the first time, doesn't this if statement always return IDLE and therefore the tick method always return FAILURE?

I also asked the question here but didn't get answers:
https://robotics.stackexchange.com/questions/114059/nav2-distance-traveled-condition

@SteveMacenski
Copy link
Member

Please do not cross post.

Have you actually tried to use it and see that it doesn't work or just speculating looking at the software? We have a unit test that seems to point to it working [1]

[1] https://github.com/ros-navigation/navigation2/blob/main/nav2_behavior_tree/test/plugins/condition/test_distance_traveled.cpp

@SteveMacenski SteveMacenski added the question Further information is requested label Jan 10, 2025
@guidout
Copy link
Author

guidout commented Jan 14, 2025

Yes, I did test it and the condition always returns IDLE.
This is the BT I used for the test:

<root main_tree_to_execute="MainTree">
  <BehaviorTree ID="MainTree">

    <RateController hz="1.0">
      <ReactiveFallback name="CheckDistanceTravelled">
        <DistanceTraveled distance="2.0" global_frame="map" robot_base_frame="base_link"
        />

        <PipelineSequence>
          <GoalUpdatedController>
            <RecoveryNode number_of_retries="1" name="RecoveryComputePathToPose">
              <ComputePathToPose goal="{goal}" path="{path}"
                planner_id="GridBased_SmacHybrid_production_line" />
              <ClearEntireCostmap name="ClearGlobalCostmap-Context"
                service_name="global_costmap/clear_entirely_global_costmap" />
            </RecoveryNode>
          </GoalUpdatedController>
          <RecoveryNode number_of_retries="1" name="RecoveryFollowPath">
            <FollowPath path="{path}" controller_id="FollowPath_TEB_prod_line"
              goal_checker_id="general_goal_checker" />
            <ClearEntireCostmap name="ClearLocalCostmap-Context"
              service_name="local_costmap/clear_entirely_local_costmap" />
          </RecoveryNode>
        </PipelineSequence>
      </ReactiveFallback>
    </RateController>
  </BehaviorTree>
</root>

I added a print out in the distance_traveled_condition.cpp:

BT::NodeStatus DistanceTraveledCondition::tick()
{
    std::cout << "Distance Traveled Condition Status: " << status()
              << std::endl;

    if (status() == BT::NodeStatus::IDLE)
...

It always prints IDLE.

Maybe my behavior tree does not implement this condition correctly?

@SteveMacenski
Copy link
Member

SteveMacenski commented Jan 14, 2025

Can you check the test and see an error? Unfortunately, we're a bit resource constrained right now, so I do need developers to do a bit of research to help suss out their issues (if they exist). I don't have the bandwidth right now to dig into each reported issue from scratch :-)

I see that the main version of this node looks different from the link that you provided based on some hash. What branch is that from, how did you obtain that hash, and have you tested any changes as addressing the behavior (and/or looked at main for potential updates)?

It could be that your hash is from a no longer supported branch / distribution -- or based on BT.CPPv3, and we're on BT.CPPv4 now that has different behavior and definitions for states

@guidout
Copy link
Author

guidout commented Jan 14, 2025

That hash should be the latest commit from the Humble branch.
I'll do some digging and report back.
I understand your resource constraints, totally. Thanks for replying, I'll report back as I find out more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants