Skip to content

Changed behavior of tickOnce #514

@DonDoff

Description

@DonDoff

Hello, we are currently using the behaviortree library version 3.5.
When we wanted to upgrade to version 4.0.2 we encountered some interface changes.
Most of these were quickly fixed, however there is one bigger problem.
Namely the fix for preemptable nodes (https://www.behaviortree.dev/migration/#preemptable-nodes-and-treetickroot) and how they stop the flow of our trees.

We are using behavior trees in an event driven way, meaning they get ticked when an event occurs (which may not be that often).
For these trees to remain in a RUNNING state for longer periods is also a valid.
Our trees were created with the curent design of a SequenceNode in mind, where a child returning SUCCESS will tick the next child.
However with the changes for preemptable nodes, this flow is stopped.

This mean the behaviortree API as it is now does not allow us to nicely tick our trees, since tickOnce() does not call all children in the sequence.
And we do not know before hand how often we should call the tickOnce().
And tickWhileRunning() will call the tree too often on 1 event.

Is there a way to get the old behavior back?

Activity

changed the title [-]Control nodes[/-] [+]Control nodes how to tick now[/+] on Mar 6, 2023
facontidavide

facontidavide commented on Mar 7, 2023

@facontidavide
Collaborator

You will not get the old behavior back, but THERE is a solution!

What you want is to tick sporadically when an event is received.

But you must ALSO tick if the TreeNode::emitWakeUpSignal() has been invoked !

Supposing your code look like this:

while(...) 
{
  tree->tickOnce();
  waitForMyCustomEvent();
}

I can modify the code to do this:

while(...) 
{  
  do {  
    tree->tickOnce(); 
  } while( tree->wakeUpRequested() );

  waitForMyCustomEvent();
}

In this way, you should be able to make the old behavior work, because the new ControlNodes use the method TreeNode::emitWakeUpSignal() that can be detected by method wakeUpRequested() (to be implemented).

facontidavide

facontidavide commented on Mar 7, 2023

@facontidavide
Collaborator

Thinking it twice, I think this could be the default behavior of tickOnce, because it is the less confusing.

I will add a tickExactlyOnce to cover all the cases.

self-assigned this
on Mar 7, 2023
facontidavide

facontidavide commented on Mar 7, 2023

@facontidavide
Collaborator

considering that this is a big change, I will push it to version 4.1, that will be released soon. Would you please test and tell me if it works for you?

Check branch issue_514/new_tickOnce

DonDoff

DonDoff commented on Mar 7, 2023

@DonDoff
Author

Thank you! This does look promising indeed!
I'll let you know once we have tested it.

DonDoff

DonDoff commented on Mar 8, 2023

@DonDoff
Author

This indeed works as expected now, thank you!

When can we expect version 4.1?
And will it also contain: #517 ?

facontidavide

facontidavide commented on Mar 8, 2023

@facontidavide
Collaborator

I am trying to release it soon, but I still have some work to do.
yes, it will contain all the changes in master, including #517

facontidavide

facontidavide commented on Mar 13, 2023

@facontidavide
Collaborator

merged to master

changed the title [-]Control nodes how to tick now[/-] [+]Changed behavior of tickOnce[/+] on Mar 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    Changed behavior of tickOnce · Issue #514 · BehaviorTree/BehaviorTree.CPP