Description
I was testing some trees with the Delay decorator and observed some behavior that did not align with what I expected. My intuitive assumption behind the delay was wait for n secs, then start ticking my child normally, however it seems to operate as a delay between each tick of the child wait for nsecs, tick the child, and repeat. I wrote a test to demonstrate the difference between these 2 cases.
I would think the current implementation is more of a throttle decorator, i.e. tick my node every n seconds, and a delay, unless halted, would only delay ticking of a child one time. This might just be my own misunderstanding of the decorator's intention, but wanted to give it some visibility in case the expressiveness of language used can be improved.
struct DelayTest : testing::Test
{
BT::DelayNode root;
BT::AsyncActionTest action;
DelayTest() : root("delay", 300)
, action("action" )
{
root.setChild(&action);
}
~DelayTest() = default;
};
TEST_F(DelayTest, DelayTickChild)
{
action.setExpectedResult(NodeStatus::RUNNING);
BT::NodeStatus state = root.executeTick();
while (action.tickCount() == 0)
{
state = root.executeTick();
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
state = root.executeTick();
ASSERT_EQ(1, action.tickCount());
ASSERT_EQ(NodeStatus::RUNNING, state);
ASSERT_EQ(NodeStatus::RUNNING, action.status());
state = root.executeTick();
// what it currently is
ASSERT_EQ(1, action.tickCount());
// what we expected (fails)
ASSERT_EQ(2, action.tickCount());
}