Skip to content

GitLab

Commit df48199d authored by Olivier Stasse's avatar Olivier Stasse
Browse files

[clang-format] Comply to Google style.

parent 48e05f15
Pipeline #6419 failed with stage
in 3 minutes and 48 seconds
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 600 additions and 625 deletions
.clang-format 0 → 100644
View file @ df48199d
---
ColumnLimit: 80
...
doc/additionalDoc/debug-doc.h
View file @ df48199d
/**
\page debug Debugging
They are several ways to perform debugging in dynamic-graph depending on your needs or situation:
- Programmatically inside the entity in C++ will write inside a buffer in a different thread and output in a stream
(either std::cout or a file). It is detailed in \subpage subp_debug_rt_logger.
- Programmatically inside the entity in C++ using a member of the entities and the previous real-time mechanism.
It provides 4 levels of messags :(DEBUG,INFO, WARNING, ERROR). It is described in details here:
\subpage subp_logger
- Programmatically in C++ to avoid overhead with macros and handling level as an int: \subpage subp_dbg_trace
- If you just need to collect informations from signals (like rosbag). You can use
an entity called Tracer inside the graph:\subpage tracerdoc . <br>
A real time version exists
to write directly inside a memory buffer \subpage tracerrealtimedoc
They are several ways to perform debugging in dynamic-graph depending on your
needs or situation:
- Programmatically inside the entity in C++ will write inside a buffer in a
different thread and output in a stream (either std::cout or a file). It is
detailed in \subpage subp_debug_rt_logger.
- Programmatically inside the entity in C++ using a member of the entities and
the previous real-time mechanism. It provides 4 levels of messags :(DEBUG,INFO,
WARNING, ERROR). It is described in details here: \subpage subp_logger
- Programmatically in C++ to avoid overhead with macros and handling level as an
int: \subpage subp_dbg_trace
- If you just need to collect informations from signals (like rosbag). You can
use an entity called Tracer inside the graph:\subpage tracerdoc . <br> A real
time version exists to write directly inside a memory buffer \subpage
tracerrealtimedoc
**/
doc/additionalDoc/debug-logger.h
View file @ df48199d
......@@ -8,8 +8,8 @@
In order to activate the logger you need to add the following lines:
\code
#define ENABLE_RT_LOG
#include <dynamic-graph/real-time-logger.h>
#include <dynamic-graph/logger.h>
#include <dynamic-graph/real-time-logger.h>
\endcode
\subsection subsec_logger_ Initialize the output stream
......@@ -39,14 +39,16 @@ The second line specifies at which frequency the STREAM messages should be
printed.<br>
The third line specifies the level of message to accept.<br>
The fourth line returns the level of verbosity.
In this case, all messages are accepted and the STREAM message are displayed on the output streams once on five. <br>
In this case, all messages are accepted and the STREAM message are displayed on
the output streams once on five. <br>
The full list of options are:
<ul>
<li>VERBOSITY_ALL: Accept all messages</li>
<li>VERBOSITY_INFO_WARNING_ERROR: Accept messages at minimum level : INFO, WARNING, ERROR</li>
<li>VERBOSITY_WARNING_ERROR: Accept messages at minimum level : WARNING, ERROR</li>
<li>VERBOSITY_ERROR: Accept messages at minimum level : ERROR</li>
<li>VERBOSITY_INFO_WARNING_ERROR: Accept messages at minimum level : INFO,
WARNING, ERROR</li> <li>VERBOSITY_WARNING_ERROR: Accept messages at minimum
level : WARNING, ERROR</li> <li>VERBOSITY_ERROR: Accept messages at minimum
level : ERROR</li>
</ul>
......@@ -54,19 +56,23 @@ The full list of options are:
Here is some example on how to display or record some information.
\code
sendMsg("This is a message of level MSG_TYPE_DEBUG",MSG_TYPE_DEBUG, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_INFO",MSG_TYPE_INFO, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_WARNING",MSG_TYPE_WARNING, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_ERROR",MSG_TYPE_ERROR, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_DEBUG_STREAM",MSG_TYPE_DEBUG_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_INFO_STREAM",MSG_TYPE_INFO_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_WARNING_STREAM",MSG_TYPE_WARNING_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_ERROR_STREAM",MSG_TYPE_ERROR_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level MSG_TYPE_DEBUG",MSG_TYPE_DEBUG,
__FILE__,__LINE__); sendMsg("This is a message of level
MSG_TYPE_INFO",MSG_TYPE_INFO, __FILE__,__LINE__); sendMsg("This is a message of
level MSG_TYPE_WARNING",MSG_TYPE_WARNING, __FILE__,__LINE__); sendMsg("This is a
message of level MSG_TYPE_ERROR",MSG_TYPE_ERROR, __FILE__,__LINE__);
sendMsg("This is a message of level
MSG_TYPE_DEBUG_STREAM",MSG_TYPE_DEBUG_STREAM, __FILE__,__LINE__); sendMsg("This
is a message of level MSG_TYPE_INFO_STREAM",MSG_TYPE_INFO_STREAM,
__FILE__,__LINE__); sendMsg("This is a message of level
MSG_TYPE_WARNING_STREAM",MSG_TYPE_WARNING_STREAM, __FILE__,__LINE__);
sendMsg("This is a message of level
MSG_TYPE_ERROR_STREAM",MSG_TYPE_ERROR_STREAM, __FILE__,__LINE__);
logger_.countdown();
\endcode
Specifying the file with __FILE__ and the line inside the file by __LINE__ are necessary for the
STREAM messages. Indeed they are indexed using the two values. As the default value are "" and 0
the counting will be confused.
Specifying the file with __FILE__ and the line inside the file by __LINE__ are
necessary for the STREAM messages. Indeed they are indexed using the two values.
As the default value are "" and 0 the counting will be confused.
*/
doc/additionalDoc/debug-trace-doc.h
View file @ df48199d
......@@ -3,10 +3,10 @@
\section subp_dbg_trace_intro Introduction
The idea of this class and collection of MACROS is to specify
a level for a message, and record the message in a stream according to this level.
In addition there are mechanisms allowing that no time
is wasted in condition test. You can therefore let the debugging messages
inside the code without impact on performances.
a level for a message, and record the message in a stream according to this
level. In addition there are mechanisms allowing that no time is wasted in
condition test. You can therefore let the debugging messages inside the code
without impact on performances.
\section subp_dbg_trace_set_on_macros Setting up dgDEBUG macros
......@@ -31,12 +31,9 @@ are written is specified by:
\section subp_dbg_trace_using_macros Using dgDEBUG macros
To print that the beginning of a method is being executed use the following macros:
\code
dgDEBUGIN(5);
\endcode
5 here specifies the minimum level that you be specified by VP_DEBUG_MODE for this message
to be displayed.
To print that the beginning of a method is being executed use the following
macros: \code dgDEBUGIN(5); \endcode 5 here specifies the minimum level that you
be specified by VP_DEBUG_MODE for this message to be displayed.
It will generate the following output:
\code
......@@ -62,8 +59,8 @@ A message inside the code is written through:
This generates the following output:
\code
/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a test
\endcode
/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a
test \endcode
\section subp_dbg_trace_wrk_exp Working example
......
doc/additionalDoc/entity.h
View file @ df48199d
......@@ -5,45 +5,57 @@
\subsection entity_definition General definition
\image html entity.png
Despite the fact that it looks very similar to a ROS node or a CORBA/OpenRTM server, an entity is simply a C++ object.
The main idea is that this entity is providing mostly a data-driven functionnality working at very high rate (\f$ 200
Despite the fact that it looks very similar to a ROS node or a CORBA/OpenRTM
server, an entity is simply a C++ object. The main idea is that this entity is
providing mostly a data-driven functionnality working at very high rate (\f$ 200
Hz\f$ or \f$ 1 kHz \f$) and should have a minimal computational time foot-print.
For this \subpage subp_signals (or ports to use a more classical terminology) are providing a time dependency between
data. To implement this, an output signal is linked with a method of the entity. The method calls input signals or use
other means to get the needed data. It might be provided by the connection with remote computers through a middleware,
or specific protocols, but in general the external data is based upon the sensor values provided by a "Device" entity.
For this reason the signal evaluations are realized through the cascade of dependencies and start from the evaluation
of an input signal of a periodic node (in general the device). This is realized inside a \b real-time thread.
To add flexibility to a node, it is possible to add command with arguments to modify the internal behavior of the
entity or get information from the entity. As a command is in general asynchronous and rare with respect to the
data-flow scheme for the signals the command is in general executed in a \b none-real-time thread.
For this \subpage subp_signals (or ports to use a more classical terminology)
are providing a time dependency between data. To implement this, an output
signal is linked with a method of the entity. The method calls input signals or
use other means to get the needed data. It might be provided by the connection
with remote computers through a middleware, or specific protocols, but in
general the external data is based upon the sensor values provided by a "Device"
entity. For this reason the signal evaluations are realized through the cascade
of dependencies and start from the evaluation of an input signal of a periodic
node (in general the device). This is realized inside a \b real-time thread.
To add flexibility to a node, it is possible to add command with arguments to
modify the internal behavior of the entity or get information from the entity.
As a command is in general asynchronous and rare with respect to the data-flow
scheme for the signals the command is in general executed in a \b none-real-time
thread.
\subsection entity_classes Entity class
Entities are implemented as C++ classes and compiled as dynamic libraries. They can be loaded and instancied
dynamically. It is therefore necessary to specify the location of their dynamical libraries. However given the time it
might take to load the library, it is not advised to do that during a control-law computation. Entity instanciation
also implies memory allocation which is also time consuming and thus not advised inside a real-time thread.
Entities are implemented as C++ classes and compiled as dynamic libraries. They
can be loaded and instancied dynamically. It is therefore necessary to specify
the location of their dynamical libraries. However given the time it might take
to load the library, it is not advised to do that during a control-law
computation. Entity instanciation also implies memory allocation which is also
time consuming and thus not advised inside a real-time thread.
The entities will be placed in ${PREFIX}/lib/plugin (since this may change, it is advised to
check the install log or the CMakeLists.txt file to check the installation path).
The entities will be placed in ${PREFIX}/lib/plugin (since this may change, it
is advised to check the install log or the CMakeLists.txt file to check the
installation path).
\subsection entities List of entities in this package
Since most of the functionality in projects using the dynamic-graph framework
is exposed from entities, here is a short description of all the entities contained in
this package. Note that most entities are contained in a binary file that closely matches
the entities' names in the scripts; loading this file with the plugin loader will
enable creation of this entity through the factory.
is exposed from entities, here is a short description of all the entities
contained in this package. Note that most entities are contained in a binary
file that closely matches the entities' names in the scripts; loading this file
with the plugin loader will enable creation of this entity through the factory.
\li \ref tracerdoc
\li \ref tracerrealtimedoc
\subsection specific_semantics Specific semantics with entities
It is possible to derive classes and apply specific semantic for the entities. In our case we are interested in
specific control semantics: \li Tasks (more information <a
href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00089.html">here</a>) \li Features (more information <a
href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00030.html">here</a>) \li Solver (more information <a
It is possible to derive classes and apply specific semantic for the entities.
In our case we are interested in specific control semantics: \li Tasks (more
information <a
href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00089.html">here</a>)
\li Features (more information <a
href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00030.html">here</a>)
\li Solver (more information <a
href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00078.html">here</a>)
*/
doc/additionalDoc/extension.h
View file @ df48199d
......@@ -5,21 +5,24 @@
\subsection use_programmatically General introduction
For control purposes the main use of this package is to create new entities and connect them through signals.
For control purposes the main use of this package is to create new entities and
connect them through signals.
Objects, which are derived from Entities (base class dynamicgraph::Entity), can be
declared within the code and compiled as shared libraries (.so/.dll files).
Objects, which are derived from Entities (base class dynamicgraph::Entity), can
be declared within the code and compiled as shared libraries (.so/.dll files).
These libraries can be loaded at run-time using the PluginLoader methods,
and at the same time register their class names to the Factory (see the
examples in the <a href="http://projects.laas.fr/gepetto/doc/stack-of-tasks/sot-core/master/doxygen-html">sot-core
examples in the <a
href="http://projects.laas.fr/gepetto/doc/stack-of-tasks/sot-core/master/doxygen-html">sot-core
documentation</a> for advanced control examples).
The Factory can then create instances of these objects and subsequently
register them in the Pool. From the pool they can be listed, accessed, and acted upon
(see PoolStorage documentation). Basic commands defined by entities include
register them in the Pool. From the pool they can be listed, accessed, and acted
upon (see PoolStorage documentation). Basic commands defined by entities include
signal connection graph file generation, help and name print, and signals.
This is usually done through a scripting language such as python (see
<a hef="https://github.com/stack-of-tasks/dynamic-graph-python">dynamic-graph-python</a>)
<a
hef="https://github.com/stack-of-tasks/dynamic-graph-python">dynamic-graph-python</a>)
The singletons made available by including the corresponding headers in this
module are:
......@@ -30,13 +33,15 @@ For an example of a program creating entities in C++, see the unit test
test_pool.cpp (in your package source directory/tests).
\subsection Tutorial
A tutorial is available <a href="http://stack-of-tasks.github.io/dynamic-graph-tutorial/">here</a>.
It is providing a step-by-step way of building an entity
A tutorial is available <a
href="http://stack-of-tasks.github.io/dynamic-graph-tutorial/">here</a>. It is
providing a step-by-step way of building an entity
\section sec_htw_helpers Helpers
When writing entities you might use some macros which are very useful to write your class.
When writing entities you might use some macros which are very useful to write
your class.
\subsection subsec_howto_typedef Entity helpers
......@@ -48,13 +53,13 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
<ul>
<li> <b>DYNAMIC_GRAPH_ENTITY_DECL()</b>:
This macro creates a method <b>getClassName()</b> which returns the class name.</li>
This macro <b>should</b> be used in the declaration of the class.
This macro creates a method <b>getClassName()</b> which returns the class
name.</li> This macro <b>should</b> be used in the declaration of the class.
</li>
<li> <b>DYNAMICGRAPH_FACTORY_ENTITY_PLUGIN(classtype,classname)</b>
This macros creates the methods necessary to have a factory building the C++ class
<b>classtype</b> from the string <b>classname</b>.
This macro <b>should</b> be used in the implementation of the class.
This macros creates the methods necessary to have a factory building the C++
class <b>classtype</b> from the string <b>classname</b>. This macro
<b>should</b> be used in the implementation of the class.
</li>
</ul>
......@@ -64,15 +69,12 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
<li> Macro for input signals
<ul>
<li> <b>DECLARE_SIGNAL_IN(signal_name,type)</b>:
Declare an input time dependent signal as a field of the class with the following name:
\code
m_signal_nameSIN
\endcode
Declare an input time dependent signal as a field of the class with the
following name: \code m_signal_nameSIN \endcode
</li>
<li> <b>CONSTRUCT_SIGNAL_IN(signal_name,type)</b>:
This macro is used in the constructor of the entity class handling this signal.
It is calling the signal constructor and set the signal name to:
\code
This macro is used in the constructor of the entity class handling this
signal. It is calling the signal constructor and set the signal name to: \code
EntityClassName(entity-name)::input(type)::signal_name
\endcode
</ul>
......@@ -80,32 +82,24 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
<li> Macro for output signals
<ul>
<li> <b>DECLARE_SIGNAL_OUT(signal_name,type)</b>:
Declare an output time dependent signal as a field of the class with the following name:
\code
m_signal_nameSOUT
\endcode
It also declares a method with the following pattern:
\code
type signal_nameSOUT_function(type &,int)
\endcode
Declare an output time dependent signal as a field of the class with the
following name: \code m_signal_nameSOUT \endcode It also declares a method with
the following pattern: \code type signal_nameSOUT_function(type &,int) \endcode
The second pattern is the time when calling the output.
</li>
<li> <b>CONSTRUCT_SIGNAL_OUT(signal_name,type)</b>
This macro is used in the constructor of the entity class handling this signal.
It creates the binding to the method described previously, and set the signal name to:
\code
EntityClassName(entity_name)::output(type)::signal_name
This macro is used in the constructor of the entity class handling this
signal. It creates the binding to the method described previously, and set the
signal name to: \code EntityClassName(entity_name)::output(type)::signal_name
\endcode
where entity_name is the name of the entity currently instanciated.
</li>
<li> <b>DEFINE_SIGNAL_OUT_FUNCTION(signal_name, type)</b>:
This macro is used when implementing the method specific to the output signal.
It is used in the main body of the entity class to declare the header of the method
with the following pattern:
\code
type EntityClassName::signal_nameSOUT_function(type &, int iter)
\endcode
This macro is used when implementing the method specific to the output
signal. It is used in the main body of the entity class to declare the header of
the method with the following pattern: \code type
EntityClassName::signal_nameSOUT_function(type &, int iter) \endcode
</li>
</ul>
......@@ -113,8 +107,8 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
</li> Inner signals
<ul>
<li> <b> DECLARE_SIGNAL_INNER(signal_name,type)</b>
Inner signal are signal that depend on a state of the entity and not on input signals.
This macro declares an inner signal with the following pattern:
Inner signal are signal that depend on a state of the entity and not on
input signals. This macro declares an inner signal with the following pattern:
\code
m_signal_nameSINNER
\endcode
......@@ -124,11 +118,13 @@ The header <b>entity-helper.h</b> is defining a type called EntityClassName
\endcode
</li>
<li> <b>DEFINE_SIGNAL_INNER_FUNCTION(signal_name,type)</b>
This macro is used to implement the method related to signal_name. More precisely
it provides the header of the member function(i.e. method) declaration.
This macro is used to implement the method related to signal_name. More
precisely it provides the header of the member function(i.e. method)
declaration.
</li>
<li><b>DECLARE_SIGNAL_INNER_FUNCTION(signal_name,type)</b>
This macros declares the member function used to handle the access to this signal.
This macros declares the member function used to handle the access to this
signal.
</li>
</ul>
</ul>
......
doc/additionalDoc/factory.h
View file @ df48199d
......@@ -2,6 +2,6 @@
\page subp_factory Factory
\section sec_factory Factory
The class \ref dynamicgraph::FactoryStorage is a singleton which register the entity classes and which is allowing the
instancation of such classes.
The class \ref dynamicgraph::FactoryStorage is a singleton which register the
entity classes and which is allowing the instancation of such classes.
*/
doc/additionalDoc/graph.h
View file @ df48199d
......@@ -6,14 +6,16 @@ In this package, the graph considered are directed graphs.
In dynamic-graph a graph is build with:
- computational nodes which are entities \subpage subpage_entities.
- directed edges which are created by connecting input and output signals \subpage subp_signals.
- managing the nodes is done through a factory \subpage subp_factory providing classes and a way to create instances
from this list of classes.
- directed edges which are created by connecting input and output signals
\subpage subp_signals.
- managing the nodes is done through a factory \subpage subp_factory providing
classes and a way to create instances from this list of classes.
- the instances of node are handled through a pool \subpage subp_pool
We strongly recommend to use a scripting language such as Python to
manage the graph.
See <c>dynamic-graph-python</c> for more information on binding dynamic-graph with Python.
See <c>dynamic-graph-python</c> for more information on binding dynamic-graph
with Python.
It is possible to display the graph of entities \subpage writegraphdoc
......
doc/additionalDoc/installation.h
View file @ df48199d
......@@ -13,7 +13,8 @@ dynamic-graph depends on:
\section sec_inst_get_src Getting the source
The sources are available through github at the following URL:
<a href="https://github.com/stack-of-tasks/dynamic-graph">https://github.com/stack-of-tasks/dynamic-graph</a>
<a
href="https://github.com/stack-of-tasks/dynamic-graph">https://github.com/stack-of-tasks/dynamic-graph</a>
To clone:
\code
......
doc/additionalDoc/introduction.h
View file @ df48199d
......@@ -3,63 +3,65 @@
\section intro_dynamicGraph Introduction
The dynamic-graph package is used to connect computation nodes, "entities"
together using a graph system, akin to what Simulink does. Entities are connected
through input and output signals.
With the building blocks this package provides, you can easily create a full computation graph
for a given problem. It is the basis for the stack of tasks operation.
together using a graph system, akin to what Simulink does. Entities are
connected through input and output signals. With the building blocks this
package provides, you can easily create a full computation graph for a given
problem. It is the basis for the stack of tasks operation.
\subsection controlgraph Exemple: Real-time control
<p>To give a more concrete example, the real-time control used by the Gepetto group for the humanoid robot HRP-2
is detailled.</p>
<p>
Real-time control system are usually driven by a cyclic computational node which
needs to send a control reference value to each motors of a robot. To compute this
control reference values, sensor values need to be provided.
In the Stack-Of-Tasks special entities called Device are used to
provide an abstract interface to the hardware.</p>
A scheme of the real-time control graph used for the humanoid robot HRP-2 is depicted in the following figure:
<p>To give a more concrete example, the real-time control used by the Gepetto
group for the humanoid robot HRP-2 is detailled.</p> <p> Real-time control
system are usually driven by a cyclic computational node which needs to send a
control reference value to each motors of a robot. To compute this control
reference values, sensor values need to be provided. In the Stack-Of-Tasks
special entities called Device are used to provide an abstract interface to the
hardware.</p> A scheme of the real-time control graph used for the humanoid
robot HRP-2 is depicted in the following figure:
\image html Concept-Software-Fig.png
You can find an example of a real example of control graph at \ref writegraphdoc.
You can find an example of a real example of control graph at \ref
writegraphdoc.
<p>The device therefore has a specific input which should contain the control vector.
This control vector is the result of a computation solving a control problem.
The entity in charge of solving this control problem is called "Solver" in the previous
figure.
In the SoT framework it is often cast as an optimization problem.
This optimization problem is build using a control "Task" (not to be confused with the
general word task). A control "Task" regulates the difference with a "Feature" computed
on the current robot state and a "Desired Feature". For instance when walking, the regulated
feature is the robot's Center-Of-Mass (CoM) position. The "Feature" is computed using a
library using the robot model and the sensor value. The entity making this computation is "Dyn".
A walking pattern generator using foot-steps position given in advance generates the desired
value for the CoM.
Note that the "Dyn" entity uses the sensor provided by the entity "Robot". </p>
<p>The device therefore has a specific input which should contain the control
vector. This control vector is the result of a computation solving a control
problem. The entity in charge of solving this control problem is called "Solver"
in the previous figure. In the SoT framework it is often cast as an optimization
problem. This optimization problem is build using a control "Task" (not to be
confused with the general word task). A control "Task" regulates the difference
with a "Feature" computed on the current robot state and a "Desired Feature".
For instance when walking, the regulated feature is the robot's Center-Of-Mass
(CoM) position. The "Feature" is computed using a library using the robot model
and the sensor value. The entity making this computation is "Dyn". A walking
pattern generator using foot-steps position given in advance generates the
desired value for the CoM. Note that the "Dyn" entity uses the sensor provided
by the entity "Robot". </p>
<p>
From a pure computer science viewpoint we wish to avoid recomputing data such as articular Jacobians
when this is unnecessary. Therefore the data generated by an entity through signals may have two types of
dependencies: one dependency related to time and dependencies on other signals. Internally an entity
does not recompute the data if no new information is available, it is simply providing the same information
computed before. Please note that this package provides only the computational framework to realize
the data dependency and the entities. Solvers, libraries to compute mechanical quantities are provided
in different packages.
From a pure computer science viewpoint we wish to avoid recomputing data such as
articular Jacobians when this is unnecessary. Therefore the data generated by an
entity through signals may have two types of dependencies: one dependency
related to time and dependencies on other signals. Internally an entity does not
recompute the data if no new information is available, it is simply providing
the same information computed before. Please note that this package provides
only the computational framework to realize the data dependency and the
entities. Solvers, libraries to compute mechanical quantities are provided in
different packages.
</p>
<p>
Finally in order to dynamically create a graph, it is possible \b on-line to load classes of entities and
create instances of entities.</p>
Finally in order to dynamically create a graph, it is possible \b on-line to
load classes of entities and create instances of entities.</p>
\subsection Functionnalities
\li Support for extensions and modules using dynamic link libraries
\li Template-based signal definition, independent
\li Type-safe connection of input and output signals
\li On-demand signal computation as well as a caching system for signal values allow fast
computation of signal values, which is a critical point for real-time systems\n
See \ref scriptingabout
\li On-demand signal computation as well as a caching system for signal values
allow fast computation of signal values, which is a critical point for real-time
systems\n See \ref scriptingabout
*/
doc/additionalDoc/package.h
View file @ df48199d
......@@ -22,16 +22,19 @@ The software graph structure is detailled in \subpage p_graph
For debugging your entities detailed instructions are given in \subpage debug
For citing the software in your research work please refer to \subpage subp_references
For citing the software in your research work please refer to \subpage
subp_references
\namespace dynamicgraph This is the namespace where every object and class of this library is located.
\namespace dynamicgraph This is the namespace where every object and class of
this library is located.
\defgroup debug Debugging
\defgroup dgraph Core classes and objects
@{
Classes, entities and binaries that make up the core of the dynamic-graph library are listed here.
Classes, entities and binaries that make up the core of the dynamic-graph
library are listed here.
@}
\defgroup signals Signals
......@@ -40,11 +43,13 @@ This part provides the mechanism to transfer information
from one entity to another. There are three main types of signals,
all deriving from the common class dynamicgraph::SignalBase :
\li dynamicgraph::Signal : a "normal" signal, passing data around \b by \b value
\li dynamicgraph::SignalPtr : a signal used for efficient passing of large data, by reference (or rather, C pointers)*
\li dynamicgraph::SignalTimeDependent : a signal that enforces a time dependency between other signals,
making sure its inputs are up to date on access, using a incrementing time tick as reference.
\li dynamicgraph::SignalPtr : a signal used for efficient passing of large data,
by reference (or rather, C pointers)* \li dynamicgraph::SignalTimeDependent : a
signal that enforces a time dependency between other signals, making sure its
inputs are up to date on access, using a incrementing time tick as reference.
\n* Note: this may cause a problem if this package is used in a multithreaded program.
\n* Note: this may cause a problem if this package is used in a multithreaded
program.
Signals can be grouped together using dynamicgraph::SignalArray.
......@@ -54,8 +59,8 @@ For more information, please see the individual signal pages.
\b Samples
\li The following code ensures the jacobian output signal uses up-to-date values for its
computations, when accessed.
\li The following code ensures the jacobian output signal uses up-to-date values
for its computations, when accessed.
\code
// This signal returns the Jacobian of the current value
......
doc/additionalDoc/pool.h
View file @ df48199d
/**
\page subp_pool Pool
\section pool Pool
The class \ref dynamicgraph::PoolStorage keeps track of the entities instanciated with the factory.
The entities are the graph nodes. Signals are constructed during the class instanciation, they do not live
independently from the entities. Signals are the directed edges of the graph. The pool can write a file representing
the graph of entities.
The class \ref dynamicgraph::PoolStorage keeps track of the entities
instanciated with the factory. The entities are the graph nodes. Signals are
constructed during the class instanciation, they do not live independently from
the entities. Signals are the directed edges of the graph. The pool can write a
file representing the graph of entities.
*/
doc/additionalDoc/references.h
View file @ df48199d
......@@ -7,8 +7,8 @@ Please when referencing the Stack-Of-Tasks use the following reference:
\anchor Mansard2009
<b> <a href="https://hal-lirmm.ccsd.cnrs.fr/lirmm-00796736/document">
"A versatile Generalized Inverted Kinematics implementation for collaborative working humanoid robots: The Stack Of
Tasks"</a>
"A versatile Generalized Inverted Kinematics implementation for collaborative
working humanoid robots: The Stack Of Tasks"</a>
</b>,
<em>N. Mansard, O. Stasse, P. Evrard, A. Kheddar,</em>
Int. Conf. on Autonomous Robots, ICAR, 2009
......
doc/additionalDoc/signal.h
View file @ df48199d
......@@ -2,11 +2,10 @@
\page subp_signals Signals
\section sec_sigintro Signals
Entities can output different types of signals. To guarante real-time perforamces, signals are implemented
using C++ and mecanism which have a low time foot-print.
All signals are templated by a Time
tick type parameter (which is used in the caching of signals) - usually \c int. Signals
are also templated after the type of data they accept or provide. For example:
(example)
For a more detailed programmer-oriented description of signals, please see \ref signals
Entities can output different types of signals. To guarante real-time
perforamces, signals are implemented using C++ and mecanism which have a low
time foot-print. All signals are templated by a Time tick type parameter (which
is used in the caching of signals) - usually \c int. Signals are also templated
after the type of data they accept or provide. For example: (example) For a more
detailed programmer-oriented description of signals, please see \ref signals
*/