flexbe_behavior_engine
flexbe_behavior_engine copied to clipboard
inaccurate /flexbe/behavior_update message
Hi, I found that the /flexbe/behavior_update can be inaccurate, sometimes state update message can be missing or repeated and sometimes the order of the states update messages can be confusing, especially when behaviors are executed by behavior action without flexbe_app.
Looking forward to a response.
Was able to reproduce the issue when using the action server. I will take a look and let you know.
The issue of not updating the action server should be fixed by the above commit.
Without digging too much into the FlexBE internals, there are two modes for running a behavior: one being controller and one not controlled. So far, only running the user interface was enabling the controlled mode and thus, providing updates to the behavior mirror. Now this is changed so that running the mirror itself is used as an indication whether updates should be sent.
@pschillinger It's solved in the develop
branch. Thanks!! When do you plan to merge it into master?
Thanks for the feedback! I plan the next merge for around end of next week.
Sorry for later feedback, the state update works well now. Another little suggestion, If /behavior_update message can be latched in default? Then we can always know which state is active now. Now the message is just published on enter of each state, if some state lasts long time, I cannot know the behavior is in which state if I monitor in process. @pschillinger
I need to know which behavior is currently running. I planned to subscribe to the topic in question but it seems only to be available if the GUI is running. But I need to run FlexBE in autonomous mode without operator interaction. @pschillinger: Is there any way to achieve this? Also, I agree with @zengxiaolei about latching.