|
3 | 3 | Nodes |
4 | 4 | ===== |
5 | 5 |
|
6 | | -Nodes are the building blocks when populating the :ref:`Pipeline`. Each node provides a specific functionality on the DepthaI, a set of configurable |
| 6 | +Nodes are the building blocks when populating the :ref:`Pipeline`. Each node provides a specific functionality on the DepthAI, a set of configurable |
7 | 7 | properties and inputs/outputs. After you create a node on a pipeline, you can also configure it as desired and link it to other nodes. |
8 | 8 |
|
9 | | -.. rubric:: Outputs and inputs |
| 9 | +On the table of contents (left side of the page) all nodes are listed under the :code:`Node` entry. You can click on them to find out more. |
| 10 | + |
| 11 | +.. rubric:: Inputs and outputs |
| 12 | + |
| 13 | +Each node can have zero, one or multiple inputs and outputs. For example :ref:`SystemLogger` node has no inputs and 1 output and :ref:`EdgeDetector` has |
| 14 | +2 inputs and 1 output, as shown below. :ref:`Script` node can have any number of inputs/ouputs. |
| 15 | + |
| 16 | +.. code-block:: |
| 17 | +
|
| 18 | + ┌───────────────────┐ |
| 19 | + inputImage │ │ |
| 20 | + ──────────────►│ │ |
| 21 | + │ │ outputImage |
| 22 | + │ EdgeDetector ├───────────► |
| 23 | + inputConfig │ │ |
| 24 | + ──────────────►│ │ |
| 25 | + │ │ |
| 26 | + └───────────────────┘ |
| 27 | + EdgeDetector node has 2 inputs and 1 output |
10 | 28 |
|
11 | | -Each node can have zero, one or multiple inputs and outputs. For example :ref:`SystemLogger` node has no inputs and 1 output and :ref:`StereoDepth` has |
12 | | -2 inputs and 6 outputs. |
13 | 29 |
|
14 | 30 | .. rubric:: Node input |
15 | 31 |
|
16 | | -Node input queue is a queue for the :ref:`Messages`. It can be linked with other node's output (that's how you link up nodes). Node inputs are |
17 | | -configurable - with :code:`input.setBlocking(bool)` and :code:`input.setQueueSize(num)`. Default behaviour is blocking and a queue size of 8 messages. |
| 32 | +Node input queue is a queue for :ref:`Messages`. It can be linked with other node's output (that's how you link up nodes). Node inputs are |
| 33 | +configurable - with :code:`input.setBlocking(bool)` and :code:`input.setQueueSize(num)`, eg. :code:`edgeDetector.inputImage.setQueueSize(10)`. |
18 | 34 | If the input queue fills up, behavior of the input depends on blocking attribute. |
19 | | -If blocking is enabled, new messages will be discarded until user gets the old messages. If blocking is disabled, new messages will push out old messages. |
| 35 | + |
| 36 | +Let's say we have linked :ref:`ColorCamera` :code:`preview` output with :ref:`NeuralNetwork` :code:`input` input. |
| 37 | + |
| 38 | +.. code-block:: |
| 39 | +
|
| 40 | + ┌─────────────┐ ┌───────────────┐ |
| 41 | + │ │ │ │ |
| 42 | + │ │ preview input │ │ |
| 43 | + │ ColorCamera ├───────────────────►│ NeuralNetwork │ |
| 44 | + │ │ [ImgFrame] │ │ |
| 45 | + │ │ │ │ |
| 46 | + └─────────────┘ └───────────────┘ |
| 47 | +
|
| 48 | +If **input is set to blocking mode**, and input queue fills up, no new messages from ColorCamera will be able to enter the input queue. This means ColorCamera |
| 49 | +will block and wait with sending its messages until it can push the message to the queue of NeuralNetwork input. If ColorCamera preview is connected to |
| 50 | +multiple inputs, the same behavior implies, with the messages being pushed sequentially to each input. |
| 51 | + |
| 52 | +.. warning:: |
| 53 | + Depending on pipeline configuration, this can sometimes lead to pipeline freezing, if some blocking input isn't being properly consumed. |
| 54 | + |
| 55 | +If **blocking is disabled**, new messages will push out old messages. This eliminates the risk of pipeline freezing, but can result in dropped messages (eg. :ref:`ImgFrame`). |
20 | 56 |
|
21 | 57 | .. rubric:: Node output |
22 | 58 |
|
23 | | -Node outputs :ref:`Messages`. There is no output queue per se, but some nodes do have a configurable output message pool. |
24 | | -Output message pool is a reserved memory region (to reduce memory fragmentation) that holds output messages. |
25 | | -After the node creates an output message (for example :ref:`ImgFrame`), it will send it to other nodes as specified when linking the inputs/outputs of the node. |
| 59 | +Node outputs :ref:`Messages`. Some nodes have a configurable output message pool. **Output message pool** is a reserved memory region (to reduce memory |
| 60 | +fragmentation) that holds output messages. After the node creates an output message (for example :ref:`ImgFrame`), it will send it to other nodes as |
| 61 | +specified when linking the inputs/outputs of the node. |
26 | 62 | Currently, some nodes (:ref:`VideoEncoder`, :ref:`NeuralNetwork`, :ref:`ImageManip`, :ref:`XLinkIn`) can have the pool size configured. |
27 | 63 | The size of the pool specifies how many messages can be created and sent out while other messages are already |
28 | | -somewhere in the pipeline. When all the messages from pool are sent out and none yet returned, that is when the node will block and |
29 | | -wait until a message is returned to the pool (not used by any node in the pipeline anymore) |
| 64 | +somewhere in the pipeline. |
30 | 65 |
|
31 | | -On the table of contents (left side of the page) all nodes are listed under the :code:`Node` entry. You can click on them to find out more. |
| 66 | +.. warning:: |
| 67 | + When all the messages from pool are sent out and none yet returned, that's when the node will block (freeze) and wait until a message is released (not used by any node in the pipeline). |
32 | 68 |
|
33 | 69 | .. toctree:: |
34 | 70 | :maxdepth: 0 |
|
0 commit comments