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

TreeExecutionServer status is misleading on exception #105

Open
b-adkins opened this issue Dec 13, 2024 · 0 comments
Open

TreeExecutionServer status is misleading on exception #105

b-adkins opened this issue Dec 13, 2024 · 0 comments

Comments

@b-adkins
Copy link

Problem Statement

On exceptions, BT::TreeExecutionServer doesn't tell anybody. Notably, the tree view stays stuck in RUNNING in Groot2 forever.

Detailed Behavior

The BT::TreeExecutionServer catches exceptions from TreeNodes. It dutifully logs them to ROS at the ERROR level. However, it does not tell external interfaces about this. The last reported status is RUNNING in:

  • Any BT::StatusChangeLogger
  • Groot2 (which uses the Groot2Publisher, a child of StatusChangeLogger)

To reproduce

  1. Make a custom behavior. Throw an exception with it.
  2. Add it to a behavior tree
  3. Run Groot2 in Real-time monitor mode
  4. Run the BT::TreeExecutionServer. Send a tree action goal with a ros2 action send_goal command. The action client should report failure.
  5. Observe the server's ROS log (for a BT::StatusChangeLogger like in the tutorial). The last status is RUNNING
  6. Run Groot2 introspection (free for small trees) and see that the most recent node is highlighted in orange.

Cause

Most of TreeExecutionServer::execute is wrapped in a try block that catches all exceptions and reports them to the ROS action server. It skips ticking the tree and thus the events that trigger a BT::StatusChangeLogger, as well as many of the callbacks that application developers might use to report status.

Suggested workaround

One could write their custom behaviors to not throw exceptions. Or...

Since you are using BT::TreeExecutionServer, it does report exceptions - via the ROS2 action interface. Either use the action client or the hidden action topic to see that the goal has failed.

Suggested fix

The many tick callbacks make it possible to appear to the server that you're ticking the tree when actually you skipped a tick. If they return FAILURE, the server stops ticking -- there are no fallbacks from the root node. Following that philosophy, once in the main loop, an exception would be equivalent to a failed tick. So I think it makes sense to return NodeStatus::FAILURE on exceptions too.

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

No branches or pull requests

1 participant