This module defines the configuration of the copper runtime.
The configuration is a directed graph where nodes are tasks and edges are connections between tasks.
The configuration is serialized in the RON format.
The configuration is used to generate the runtime code at compile time.
CopperList is the main data structure used by Copper to communicate between tasks.
It is a queue that can be used to store preallocated messages between tasks in memory order.
CuRuntime is the heart of what copper is running on the robot.
It is exposed to the user via the copper_runtime macro injecting it as a field in their application struct.
Generates the CopperList content type from a config.
gen_cumsgs!(“path/to/config.toml”)
It will create a new type called CuMsgs you can pass to the log reader for decoding:
This is the configuration of a component (like a task config or a monitoring config):w
It is a map of key-value pairs.
It is given to the new method of the task implementation.
CuConfig is the programmatic representation of the configuration graph.
It is a directed graph where nodes are tasks and edges are connections between tasks.
This structure represents a loop in the execution plan.
It is used to represent a sequence of Execution units (loop or steps) that are executed
multiple times.
if loop_count is None, the loop is infinite.
This structure maintains the entire memory needed by Copper for one loop for the inter tasks communication within a process.
P or Payload is typically a Tuple of various types of messages that are exchanged between tasks.
N is the maximum number of in flight Copper List the runtime can support.
This is the main structure that will be injected as a member of the Application struct.
CT is the tuple of all the tasks in order of execution.
CL is the type of the copper list, representing the input/output messages for all the tasks.
This is a placeholder task for a sink task for the simulations.
It basically does nothing in place of a real driver so it won’t try to initialize any hardware.
This is a placeholder task for a source task for the simulations.
It basically does nothing in place of a real driver so it won’t try to initialize any hardware.
A KeyFrame is recording a snapshot of the tasks state before a given copperlist.
It is a double encapsulation: this one recording the culistid and another even in
bincode in the serialized_tasks.
A running Robot clock.
The clock is a monotonic clock that starts at an arbitrary reference time.
It is clone resilient, ie a clone will be the same clock, even when mocked.
Each concurrent sublogger is tracked through a section header.
They form a linked list of sections.
The entry type is used to identify the type of data in the section.
A Handle to a Buffer.
For onboard usages, the buffer should be Pooled (ie, coming from a preallocated pool).
The Detached version is for offline usages where we don’t really need a pool to deserialize them.
The time of validity of a message can be more than one time but can be a time range of Tovs.
For example a sub scan for a lidar, a set of images etc… can have a range of validity.
A CuPool is a pool of buffers that can be shared between different parts of the code.
Handles can be stored locally in the tasks and shared between them.
A Src Task is a task that only produces messages. For example drivers for sensors are Src Tasks.
They are in push mode from the runtime.
To set the frequency of the pulls and align them to any hw, see the runtime configuration.
Note: A source has the privilege to have a clock passed to it vs a frozen clock.
Adds #[copper_runtime(config = “path”, sim_mode = false/true)] to your application struct to generate the runtime.
if sim_mode is omitted, it is set to false.
This will add a “runtime” field to your struct and implement the “new” and “run” methods.