You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -9,6 +9,11 @@ When designing reactive Behavior Trees, it is important to understand 2 main con
9
9
10
10
If you Google those words, you will read many good articles about this topic.
11
11
12
+
!!! info "Defintions"
13
+
**Concurrency** is when two or more tasks can start, run, and complete in overlapping time periods. It doesn't necessarily mean they'll ever both be running at the same instant.
14
+
15
+
**Parallelism** is when tasks literally run at the same time in different threads, e.g., on a multicore processor.
16
+
12
17
BT.CPP executes all the nodes **Concurrently**, in other words:
13
18
14
19
- The Tree execution engine itself is single-threaded.
@@ -51,43 +56,42 @@ class SleepNode : public BT::StatefulActionNode
51
56
52
57
static BT::PortsList providedPorts()
53
58
{
54
-
// amount of milliseconds that we want to sleep
55
-
return{ BT::InputPort<int>("msec") };
59
+
// amount of milliseconds that we want to sleep
60
+
return{ BT::InputPort<int>("msec") };
56
61
}
57
62
58
63
NodeStatus onStart() override
59
64
{
60
-
int msec = 0;
61
-
getInput("msec", msec);
62
-
if( msec <= 0 )
63
-
{
64
-
// No need to go into the RUNNING state
65
-
return NodeStatus::SUCCESS;
66
-
}
67
-
else {
68
-
using namespace std::chrono;
69
-
// once the deadline is reached, we will return SUCCESS.
// The halt() method can not kill the spawned thread :()
222
226
// void halt();
223
-
}
224
227
};
225
228
```
226
229
227
230
As you can see, this looks more complicated than the version we implemented
228
231
first, using `BT::StatefulActionNode`.
229
232
This pattern can still be useful in some case, but you must remember that introducing multi-threading make things more complicated and **should be avoided by default**.
233
+
234
+
## Advanced example: client / server communication
235
+
236
+
Frequently, people using BT.CPP execute the actual task in a different process.
237
+
238
+
A typical (and recommended) way to do this in ROS is using [ActionLib](http://wiki.ros.org/actionlib).
239
+
240
+
ActionLib provides exactly the kind of API that we need to implement correctly an asynchronous behavior:
241
+
242
+
1. A non-blocking function to start the Action.
243
+
2. A way to monitor the current state of execution of the Action.
244
+
3. A way to retrieve the result or the error messages.
245
+
4. The avility to preempt / abort an action that is being executed.
246
+
247
+
None of these operations are "blocking", therefore we don't need to spawn our own thread.
248
+
249
+
More generally, let's assume that the developer has their own inter-processing communication, with a client/server relationship between the BT executor and the actual service provider.
250
+
251
+
The corresponding **pseudo-code** implementation will look like this:
0 commit comments