-
Notifications
You must be signed in to change notification settings - Fork 10
Home
CS::APEX (Algorithm Prototyper and EXperimentor for Cognitive Systems) is a framework based on synchronous dataflow and event-based message passing that aims to speed up prototyping of new robotic algorithms using visual programming aspects. The framework provides different features to allow users to prototype new algorithms more quickly. Calculations are represented by a nodes in a directed graph.
Manipulation of this execution graph is possible through a simple graphical user interface that allows spawning and deleting nodes, adding and removing edges and arranging those elements visually. To speed up the prototyping process, other features like undo/redo mechanisms and profiling are implemented as well. Finally there exists an easy to use parameter system that generates UI controls for each block and allows parameter tuning and optimization.
The framework itself does not provide any predefined computation nodes and does not depend on specific message definitions or node types. These details are instead implemented in distinct plugin libraries that extend the functionality of the whole system. This way maximal independence can be achieved, while new modules can easily be added to introduce nodes and message types.
cs::APEX is implemented using the build system of ROS, which is called catkin. If you are unfamiliar with it, please have a quick look at their provided Tutorials.
For managing plug-ins, ROS also provides a library called PluginLib, but if you only want to use this framework, the How-To's on the bottom should be sufficient.
Furthermore basic knowledge of QT is required, since it is used throughout the framework for signals/slots, thread management and of course UI elements.
Internally the main program manages a computation graph.
Nodes represent the central aspects: They can have inputs and outputs which can be connected with edges to other node's inputs and outputs.
Nodes do not have any direct influence on the user interface.
They can declare Parameterss using the class ParameterFactory which will be automatically be displayed on the UI.
In case you want to have control over the UI directly, you can implement a NodeAdapter which generates additional UI elements.
Node is an interface client classes have to implement in order to be usable in the framework.
Interfaces are still subject to change, but the essential interface looks something like this:
class Node : ...
{
public:
Node();
virtual ~Node();
void initialize(const UUID &uuid, NodeModifier *node_modifier);
void doSetup();
public:
virtual void setup(csapex::NodeModifier& node_modifier) = 0;
virtual void setupParameters(Parameterizable& parameters);
virtual void process(csapex::NodeModifier& node_modifier, csapex::Parameterizable& parameters);
virtual void reset();
...
};There are three essential functions needed:
virtual void setup(csapex::NodeModifier& node_modifier) = 0;is called when a new node is inserted into the computation graph and is used to setup I/O ports of the node.
virtual void setupParameters(Parameterizable& parameters);is called after a node has been setup and before it can reveice any messages.
This function should be used to declare Parameters using the ParameterFactory.
virtual void process(csapex::NodeModifier& node_modifier, csapex::Parameterizable& parameters);Is called iteratively whenever all input ports have received messages.
For more details on how to implement a Node, please refer to the How-to's / Tutorials.
The dataflow between nodes in cs::APEX consists of Tokens with an associated type.
This means that each connection can only send specific messages.
These messages are derived from TokenData or Message, depending on the intended meaning.
Output and Input are used to receive and send message between Nodes.
The dataflow is synchronous and homogeneous, which means that with every call to Node::process there will be one and only one message per Input.
Inputs can be made optional, which means that they do not have to be connected to an output.
Optional Inputs that are connected behave exactly the same as non-optional Inputs.
Event and Slot resemble Output and Input in that they are also used to send messages between nodes.
The main difference, however, is that Events and Slots are asynchronous, which means that a node does not have to wait until all Slots have received a message to process.
On the contrary: As soon as a Slot receives a message, this message can be handled.
Slots are therefore independent of each other. There is no single processing function to handle their messages, but each Slot is given a callback that is executed for each received message.
ParameterFactory is a class implementing the Factory pattern.
It is used to generate different types of parameters that can be added to nodes.
Most of the time, nodes therefore need not know about the exact implementation of their parameters.
Supported parameter types are:
| Parameter Type | Description | GUI Adapter |
|---|---|---|
| RangeParameter | A single value in a range [a, b] | Slider |
| IntervalParameter | An interval between two values in a range [a, b] | DualSlider |
| ValueParameter | Any value without restrictions | TextBox |
| SetParameter | A value of a given set. | ComboBox |
| BitSetParameter | A bitset where each bit can be manipulated | CheckBoxes |
| PathParameter | A path to a file or directory | File Dialog |
| TriggerParameter | A parameter without value that can trigger an event | PushButton |
| StringListParameter | A list of strings | ComboBox |
| ColorParameter | A color in RGB | ColorSelector |
| AngleParameter | An angle in radians. | Dial |
NodeAdapters are optional classes that can be implemented to accompany a Node.
They are used to generate UI elements, if there is a need for non-parameter based UI elements.
In general it should not be necessary to implement a NodeAdapter since most user interaction can be modelled using Parameters.