The most significant components of a NUClear system are the PowerPlant, Reactors, Reactions and Tasks. It is the interaction between these components that ensures data and code are easily accessible throughout the system.


The PowerPlant can be thought of as the central message system through which Reactors communicate.


Whenever a reactor emits data into the system, the PowerPlant takes ownership of the data and executes any Reactions which are subscribed to the message.

The PowerPlant is also responsible for assigning the threads on which the Tasks will run. NUClear is a multithreaded environment, with all threading logic centralised and handled by the PowerPlant. The transparent multithreading uses a threadpool with enough threads to saturate every CPU core in the system, allowing Tasks to execute on a different thread.

By centralising the threading logic, NUClear provides developers the freedom to concentrate on their Reactors instead of threading problems. The NUClear DSL provides Execution Modifiers should developers wish to execute control over how their threads will run.


A reactor can be thought of as a module. In fact, all modules in the NUClear system will be an extension of NUClear::Reactor.

During the Startup Process, the reactors for the system will be installed into the PowerPlant.

From that point on, reactors are primarily responsible for two functions; defining the Reactions and conditions under which they will process, and in some cases, emitting data to the PowerPlant as required.


Reactions provide the definitions of the Tasks which need to run when the data and/or conditions required for the reaction become available/true.

To setup a reaction, a reactor can use the functionality provided by NUClear::Reactor to subscribe to the PowerPlant for any messages or conditions of interest. Under the hood, these functions are bound by NUClear as callbacks, and it is the execution of these callbacks which will assign Tasks to a thread.

Subscriptions to the PowerPlant are made using DSL On Statements. The conditions for the request are then further defined using the keywords Trigger, With, Every and Always.

Developers can execute further control over reactions in the system with the tools provided for Managing Reactions.


A task is the current execution of a defined reaction within the system. For debugging purposes, all tasks will track the following information: