Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • cberge/dynamic-graph
  • ostasse/dynamic-graph
  • gsaurel/dynamic-graph
  • stack-of-tasks/dynamic-graph
4 results
Show changes
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 1405 additions and 287 deletions
doc/CMakeFiles/documentation.dir/progress.make deleted 100644 → 0
View file @ 02aa8dea
CMAKE_PROGRESS_1 = 2
doc/CMakeFiles/progress.marks deleted 100644 → 0
View file @ 02aa8dea
1
doc/CMakeLists.txt deleted 100644 → 0
View file @ 02aa8dea
#
# Copyright
#
# Configure package.dox file
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/package.dox.cmake
${CMAKE_CURRENT_BINARY_DIR}/package.dox
)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/html/index.html
COMMAND ${DOXYGEN_EXECUTABLE} \"${CMAKE_CURRENT_BINARY_DIR}/package.dox\"
)
ADD_CUSTOM_TARGET(documentation ALL
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/html/index.html)
#
# Install html documentation
#
# html files
INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html
DESTINATION share/doc/dynamic-graph)
# doxytag
INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.doxytag
DESTINATION share/doc/dynamic-graph/html)
# pictures
INSTALL(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/pictures
DESTINATION share/doc/dynamic-graph/html)
doc/Doxyfile.extra.in 0 → 100644
View file @ 2e7a70d5
This diff is collapsed.
doc/Makefile deleted 100644 → 0
View file @ 02aa8dea
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8
# Default target executed when no arguments are given to make.
default_target: all
.PHONY : default_target
#=============================================================================
# Special targets provided by cmake.
# Disable implicit rules so canoncical targets will work.
.SUFFIXES:
# Remove some rules from gmake that .SUFFIXES does not remove.
SUFFIXES =
.SUFFIXES: .hpux_make_needs_suffix_list
# Produce verbose output by default.
VERBOSE = 1
# Suppress display of executed commands.
$(VERBOSE).SILENT:
# A target that is always out of date.
cmake_force:
.PHONY : cmake_force
#=============================================================================
# Set environment variables for the build.
# The shell in which to execute make rules.
SHELL = /bin/sh
# The CMake executable.
CMAKE_COMMAND = /usr/bin/cmake
# The command to remove a file.
RM = /usr/bin/cmake -E remove -f
# The program to use to edit the cache.
CMAKE_EDIT_COMMAND = /usr/bin/ccmake
# The top-level source directory on which CMake was run.
CMAKE_SOURCE_DIR = /home/blue/sot-devel/dg
# The top-level build directory on which CMake was run.
CMAKE_BINARY_DIR = /home/blue/sot-devel/dg
#=============================================================================
# Targets provided globally by CMake.
# Special rule for the target edit_cache
edit_cache:
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Running CMake cache editor..."
/usr/bin/ccmake -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR)
.PHONY : edit_cache
# Special rule for the target edit_cache
edit_cache/fast: edit_cache
.PHONY : edit_cache/fast
# Special rule for the target install
install: preinstall
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Install the project..."
/usr/bin/cmake -P cmake_install.cmake
.PHONY : install
# Special rule for the target install
install/fast: preinstall/fast
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Install the project..."
/usr/bin/cmake -P cmake_install.cmake
.PHONY : install/fast
# Special rule for the target install/local
install/local: preinstall
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Installing only the local directory..."
/usr/bin/cmake -DCMAKE_INSTALL_LOCAL_ONLY=1 -P cmake_install.cmake
.PHONY : install/local
# Special rule for the target install/local
install/local/fast: install/local
.PHONY : install/local/fast
# Special rule for the target install/strip
install/strip: preinstall
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Installing the project stripped..."
/usr/bin/cmake -DCMAKE_INSTALL_DO_STRIP=1 -P cmake_install.cmake
.PHONY : install/strip
# Special rule for the target install/strip
install/strip/fast: install/strip
.PHONY : install/strip/fast
# Special rule for the target list_install_components
list_install_components:
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Available install components are: \"Unspecified\""
.PHONY : list_install_components
# Special rule for the target list_install_components
list_install_components/fast: list_install_components
.PHONY : list_install_components/fast
# Special rule for the target rebuild_cache
rebuild_cache:
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Running CMake to regenerate build system..."
/usr/bin/cmake -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR)
.PHONY : rebuild_cache
# Special rule for the target rebuild_cache
rebuild_cache/fast: rebuild_cache
.PHONY : rebuild_cache/fast
# Special rule for the target test
test:
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Running tests..."
/usr/bin/ctest --force-new-ctest-process $(ARGS)
.PHONY : test
# Special rule for the target test
test/fast: test
.PHONY : test/fast
# The main all target
all: cmake_check_build_system
cd /home/blue/sot-devel/dg && $(CMAKE_COMMAND) -E cmake_progress_start /home/blue/sot-devel/dg/CMakeFiles /home/blue/sot-devel/dg/doc/CMakeFiles/progress.marks
cd /home/blue/sot-devel/dg && $(MAKE) -f CMakeFiles/Makefile2 doc/all
$(CMAKE_COMMAND) -E cmake_progress_start /home/blue/sot-devel/dg/CMakeFiles 0
.PHONY : all
# The main clean target
clean:
cd /home/blue/sot-devel/dg && $(MAKE) -f CMakeFiles/Makefile2 doc/clean
.PHONY : clean
# The main clean target
clean/fast: clean
.PHONY : clean/fast
# Prepare targets for installation.
preinstall: all
cd /home/blue/sot-devel/dg && $(MAKE) -f CMakeFiles/Makefile2 doc/preinstall
.PHONY : preinstall
# Prepare targets for installation.
preinstall/fast:
cd /home/blue/sot-devel/dg && $(MAKE) -f CMakeFiles/Makefile2 doc/preinstall
.PHONY : preinstall/fast
# clear depends
depend:
cd /home/blue/sot-devel/dg && $(CMAKE_COMMAND) -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR) --check-build-system CMakeFiles/Makefile.cmake 1
.PHONY : depend
# Convenience name for target.
doc/CMakeFiles/documentation.dir/rule:
cd /home/blue/sot-devel/dg && $(MAKE) -f CMakeFiles/Makefile2 doc/CMakeFiles/documentation.dir/rule
.PHONY : doc/CMakeFiles/documentation.dir/rule
# Convenience name for target.
documentation: doc/CMakeFiles/documentation.dir/rule
.PHONY : documentation
# fast build rule for target.
documentation/fast:
cd /home/blue/sot-devel/dg && $(MAKE) -f doc/CMakeFiles/documentation.dir/build.make doc/CMakeFiles/documentation.dir/build
.PHONY : documentation/fast
# Help Target
help:
@echo "The following are some of the valid targets for this Makefile:"
@echo "... all (the default if no target is provided)"
@echo "... clean"
@echo "... depend"
@echo "... documentation"
@echo "... edit_cache"
@echo "... install"
@echo "... install/local"
@echo "... install/strip"
@echo "... list_install_components"
@echo "... rebuild_cache"
@echo "... test"
.PHONY : help
#=============================================================================
# Special targets to cleanup operation of make.
# Special rule to run CMake to check the build system integrity.
# No rule that depends on this can have commands that come from listfiles
# because they might be regenerated.
cmake_check_build_system:
cd /home/blue/sot-devel/dg && $(CMAKE_COMMAND) -H$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR) --check-build-system CMakeFiles/Makefile.cmake 0
.PHONY : cmake_check_build_system
doc/additionalDoc/debug-doc.h 0 → 100644
View file @ 2e7a70d5
/**
\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++, a logger 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.
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 0 → 100644
View file @ 2e7a70d5
/**
\page subp_logger Loggers
\section sec_init_rt_logger Initialization of the logger
\subsection subsec_init_rt_logger_hcpp Header and preprocessor variable
In order to activate the logger you need to add the following lines:
\code
#define ENABLE_RT_LOG
#include <dynamic-graph/logger.h>
#include <dynamic-graph/real-time-logger.h>
\endcode
\subsection subsec_logger_ Initialize the output stream
It is possible to set the output stream of the messages inside a file:
\code
dynamicgraph::RealTimeLogger::instance();
of.open("/tmp/dg-LOGS.txt",std::ofstream::out|std::ofstream::app);
dgADD_OSTREAM_TO_RTLOG (of);
dynamicgraph::RealTimeLogger::destroy();
\endcode
\section sec_use_rt_logger Using the rt_logger
\code
// Somewhere in your library
dgRTLOG() << "your message. Prefer to use \n than std::endl."
\endcode
Here the output file is "/tmp/dg-LOGS.txt".
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.
The default values "" and 0 for the counting are not well understood.
*/
doc/additionalDoc/debug-trace-doc.h 0 → 100644
View file @ 2e7a70d5
/**
\page subp_dbg_trace Debugging with macros and level
\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.
\section subp_dbg_trace_set_on_macros Setting up dgDEBUG macros
To allow message display the entity must be compiled with the macro
\code
#define VP_DEBUG 1
\endcode
Commenting or removing this macro disable all the messages specified
by the following macros.
The level up to which the messages are accepted for display is
specified by:
\code
#define VP_DEBUG_MODE 50
\endcode
In the constructor of the entity, the file where all the messages
are written is specified by:
\code
dynamicgraph::dgDEBUGFLOW.openFile("/tmp/dynamic-graph-traces.txt");
\endcode
\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.
It will generate the following output:
\code
/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#46) :# In {
\endcode
The output displays the name of the source file, the name of the method,
the line where is the macro, and the message itself.
When going out of the method:
\code
dgDEBUGOUT(5);
\endcode
This generates the following output:
\code
/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#54) :# Out }
\endcode
A message inside the code is written through:
\code
dgDEBUG(5) << "Here is a test" << std::endl;
\endcode
This generates the following output:
\code
/path_to/dynamic-graph/tests/debug-trace.cpp: testDebugTrace(#52) :Here is a
test \endcode
\section subp_dbg_trace_wrk_exp Working example
A full working example is given here:
\include tests/debug-trace.cpp
*/
doc/additionalDoc/doc-command.h 0 → 100644
View file @ 2e7a70d5
/** \page subpage_command Commands
\section subpage_command_intro Quick introduction
Commands are allowing to expand the entities.
It has no real interest in C++, and is mostly targeted to scripting languages
used to manipulate the control graph.
dynamic-graph-python provides a mecanism which is automatically binding command
to python. The main interest for a programmer is that there is no additional
lines to add. It is realized through CMake rules provided by the submodule
jrl-cmakemodules.
\section subpage_command_using Extending entities
\subsection subpage_command_setters_and_getters Setters and getters
To modify a quantity with a special method of your class, it is recommanded to
use Setter.
For instance to specify the size of the state in one entity and calls the
method setStateSize it is possible to write:
\code
docstring = "\n"
" Set size of state vector\n"
"\n";
addCommand("resize", new command::Setter<Device, unsigned int>(
*this, &Device::setStateSize, docstring));
\endcode
Getting the information of the member of the class can be realized with
the following snippet:
\code
addCommand("getTimeStep",
command::makeDirectGetter(
*this, &this->timestep_,
command::docDirectGetter("Time step", "double")));
\endcode
\subsubsection subsubpage_command_void_multiple_args Implementing a command
Templates are provided to create commands returning no value, but with up to
4 arguments.
In order to call the following method:
\code
void four_args(const int &, const int &, const int &, const int &) {
test_four_args_ = true;
}
\endcode
It is sufficient to add in the constructor:
\code
addCommand("4_args",
makeCommandVoid4(
*this, &CustomEntity::four_args,
docCommandVoid4("four args", "int", "int", "int", "int")));
\endcode
The arguments are limited to the types provided by the class Value.
\subsection subpage_command_void_multiple_args Commands returning a value
The templates with the prefix makeCommandReturnType are allowing to return
a type.
For instance to add a command returning a type with two arguments:
\code
std::string two_args_ret(const int &, const int &)
{ test_two_args_ = true; return std::string("return");}
\endcode
In the constructor, the following snippet shows to create the command:
\code
addCommand("2_args_r",
makeCommandReturnType2(
*this, &CustomEntity::two_args_ret,
docCommandVoid2("two args", "int","int")));
\endcode
\section section_calling_a_generic_command Calling a generic command
Of course calling in C++ a command amounts to call directly the method.
However in the context of writing a wrapper for another language,
one may wants to find a command and build the call.
All the commands of an entity are store in a map. The strings storing the
commands name are the map keys.
Therefore calling the previous command can be done with the following snippet:
\code
std::map<const std::string, Command *> aCommandMap =
this->getNewStyleCommandMap();
std::string cmd_name = "4_args";
std::map<const std::string, Command *>::iterator it_map;
it_map = aCommandMap.find(cmd_name);
if (it_map == aCommandMap.end())
int first_arg = 1;
Value aValue(first_arg);
std::vector<Value> values;
for (unsigned int i = 0; i < 4; i++)
values.push_back(aValue);
it_map->second->setParameterValues(values);
it_map->second->execute();
it_map->second->owner();
it_map->second->getDocstring();
\endcode
when returning a value the line with the call to execute is :
\code
Value aValue =it_map->second->execute();
\endcode
*/
doc/additionalDoc/doc-debug-real-time-logger.h 0 → 100644
View file @ 2e7a70d5
/**
\page subp_debug_rt_logger Real-time Logger
\section real_time_logger_quick_intro Quick introduction
Each entity has a protected logger_ object.
The simplest way to have information while running your graph is to initialize
it in the constructor, and then display information in the methods.
You can then change the level of information you want to display using
either the entity method setLoggerVerbosityLevel()
or the corresponding python bindings.
\section real_time_logger_modifying_entities Putting information in your
entity.
It is possible to define the periodicity of the logger:
\code
logger_.setTimeSample(0.001);
\endcode
To define the periodicity at which one wants to print information:
\code
logger_.setStreamPrintPeriod(0.005);
\endcode
Several level of verbosity are possible:
\code
logger_.setVerbosity(VERBOSITY_ALL);
\endcode
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>
</ul>
It is specified by the enum LoggerVerbosity
It is possible to display information according to various level of debug:
\code
sendMsg("This is a message of level MSG_TYPE_DEBUG", MSG_TYPE_DEBUG);
\endcode
or
\code
DYNAMIC_GRAPH_ENTITY_DEBUG (*this) << "This is a message of level
MSG_TYPE_DEBUG\n"; DYNAMIC_GRAPH_ENTITY_INFO (*this) << "This is a message of
level MSG_TYPE_INFO\n"; DYNAMIC_GRAPH_ENTITY_WARNING (*this) << "This is a
message of level MSG_TYPE_WARNING\n"; DYNAMIC_GRAPH_ENTITY_ERROR (*this) <<
"This is a message of level MSG_TYPE_ERROR\n"; DYNAMIC_GRAPH_ENTITY_DEBUG_STREAM
(*this) << "This is a message of level MSG_TYPE_DEBUG_STREAM\n";
DYNAMIC_GRAPH_ENTITY_INFO_STREAM (*this) << "This is a message of level
MSG_TYPE_INFO_STREAM\n"; DYNAMIC_GRAPH_ENTITY_WARNING_STREAM (*this) << "This is
a message of level MSG_TYPE_WARNING_STREAM\n"; DYNAMIC_GRAPH_ENTITY_ERROR_STREAM
(*this) << "This is a message of level MSG_TYPE_ERROR_STREAM\n"; \endcode
\note Thread safety. This class expects to have:
- only one reader: the one who take the log entries and write them somewhere.
- one writer at a time. Writing to the logs is **never** a blocking
operation. If the resource is busy, the log entry is discarded.
*/
doc/additionalDoc/entity.h 0 → 100644
View file @ 2e7a70d5
/**
\page subpage_entities Entities
\section section_entities Entities
\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
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 more details on command see \subpage subpage_command .
\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.
The entities will be placed in ${PREFIX}/lib/dynamic-graph-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.
\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
href="http://stack-of-tasks.github.io/sot-core/doxygen/HEAD/a00078.html">here</a>)
*/
doc/additionalDoc/extension.h 0 → 100644
View file @ 2e7a70d5
/**
\page subp_how_to_use Using this package
\section usecase How to use this package
\subsection use_programmatically General introduction
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).
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
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
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>)
The singletons made available by including the corresponding headers in this
module are:
\li dynamicgraph::FactoryStorage
\li dynamicgraph::PoolStorage
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
\section sec_htw_helpers Helpers
When writing entities you might use some macros which are very useful to write
your class.
\subsection subsec_howto_typedef Entity helpers
The header <b>entity-helper.h</b> is defining a type called EntityClassName
\section sec_howto_macros_helpers Macro helpers
\subsection subsec_howto_macros_helpers_ent Preprocessing macros for entities
<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.
</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.
</li>
</ul>
\subsection subsec_howto_macros_helpers_sig Preprocessing macros for signals
<ul>
<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
</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
EntityClassName(entity-name)::input(type)::signal_name
\endcode
</ul>
</li>
<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
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
\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
</li>
</ul>
<li>
</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:
\code
m_signal_nameSINNER
\endcode
It also creates a member function with the following pattern:
\code
type & EntityClassName::nameSINNER_function(signal_name)(type &, int)
\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.
</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.
</li>
</ul>
</ul>
*/
doc/additionalDoc/factory.h 0 → 100644
View file @ 2e7a70d5
/**
\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.
*/
doc/additionalDoc/graph.h 0 → 100644
View file @ 2e7a70d5
/**
\page p_graph Graph
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.
- commands which are expanding the capabilities of the entity
\subpage subpage_command
- 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.
It is possible to display the graph of entities \subpage writegraphdoc
*/
doc/additionalDoc/installation.h 0 → 100644
View file @ 2e7a70d5
/**
\page subp_installation Installation
\section sec_inst_dep Dependencies
dynamic-graph depends on:
<ul>
<li> boost </li>
<li> eigen </li>
<li> cmake </li>
</ul>
\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>
To clone:
\code{.sh}
git clone https://github.com/stack-of-tasks/dynamic-graph.git
\endcode
\section sec_inst_comp Compiling
\code
cd dynamic-graph
mkdir _build
cd _build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
make
\endcode
*/
doc/additionalDoc/introduction.h 0 → 100644
View file @ 2e7a70d5
/**
\page subp_concept_intro General introduction
\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.
\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:
\image html Concept-Software-Fig.png
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>
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>
\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
*/
doc/additionalDoc/package.h
View file @ 2e7a70d5
/*
* Copyright 2010,
* François Bleibel,
* Thomas Moulard,
* Olivier Stasse,
*
* CNRS/AIST
*
* This file is part of dynamic-graph.
* dynamic-graph is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public License
* as published by the Free Software Foundation, either version 3 of
* the License, or (at your option) any later version.
* dynamic-graph is distributed in the hope that it will be
* useful, but WITHOUT ANY WARRANTY; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License for more details. You should
* have received a copy of the GNU Lesser General Public License along
* with dynamic-graph. If not, see <http://www.gnu.org/licenses/>.
*/
/**
\mainpage
\section intro_dynamicGraph Introduction
The dynamic-graph aims at building computational graphs for real-time control.
It provides the basic software functionnalities.
The dynamic-graph package is used to connect computation nodes, "entities"
together using a graph system, akin to what Simulink does. 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.
A more detailed introduction is available at \subpage subp_concept_intro.
\section overview Code overview
This code implements the factory design pattern, making creation of entities
available to packages depending on the dynamic-graph API.
The installation instruction are given at \subpage subp_installation.
Objects, which are derived from Entities, can be
declared within the code and compiled to 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 SOT documentation to learn how).
The software graph structure is detailled in \subpage p_graph
The Factory can then create instances of these objects and subsequently
register them in the Pool, where they can be listed, accessed, and acted upon
(see sotPoolStorage documentation). Basic commands defined by entities include
signal connection graph file generation, help and name print, and signals.
For debugging your entities detailed instructions are given in \subpage debug
Finally, a shell (command-line) interface is made available thanks to the
Interpreter class (see the file test_shell.cpp for an example). Objects deriving from
Entity can expose their own commands by overriding the Entity's default
commandLine() method. It is possible to load a plugin to register custom
shell commands; see shell-functions and shell-procedure for an example.
For citing the software in your research work please refer to
\subpage subp_references
Some basic shell functions, and support for procedures, are also included.
For a complete list of those, load the plugin shell-functions.so and type 'help'
at the command line.
\namespace dynamicgraph This is the namespace where every object and class of
this library is located.
The public static objects (singletons) made available by including the
corresponding headers in this module are:
\li g_factory: FactoryStorage
\li g_pool: PoolStorage
\li g_shell: Interpreter
\defgroup debug Debugging
\image html pictures/use-case.svg
.
\defgroup dgraph Core classes and objects
\defgroup signals Signals
\ingroup dgraph
@{
Classes 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.
@}
\ingroup signals
\defgroup signals Signals
@{
This part provides the mechanism to transfer information
from one feature to another. There are three main types of signals,
from one entity to another. There are three main types of signals,
all deriving from the common class dynamicgraph::SignalBase :
\li dynamicgraph::Signal
\li dynamicgraph::SignalPtr
\li dynamicgraph::SignalTimeDependent
\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.
\n* Note: this may cause a problem if this package is used in a multithreaded
program.
Signals can be grouped together using dynamicgraph::SignalArray.
Signals implement a caching mechanism by storing the last computation time tick.
Signals can be plug into one another or set through shell commands.
@}
\namespace dynamicgraph This is the namespace where every object and class of this library is located.
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.
\code
// This signal returns the Jacobian of the current value
// according to the robot state
dg::SignalTimeDependent<ml::Matrix,int> jacobianSOUT;
(...)
jacobianSOUT.addDependency( positionSIN );
jacobianSOUT.addDependency( articularJacobianSIN );
\endcode
@}
*/
doc/additionalDoc/pool.h 0 → 100644
View file @ 2e7a70d5
/**
\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.
*/
doc/additionalDoc/references.h 0 → 100644
View file @ 2e7a70d5
/**
\page subp_references References
\section sec_refer References
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>
</b>,
<em>N. Mansard, O. Stasse, P. Evrard, A. Kheddar,</em>
Int. Conf. on Autonomous Robots, ICAR, 2009
\anchor Mansard2007
<b>"Task sequencing for sensor-based control"</b>,
<em>N. Mansard, F. Chaumette,</em>
IEEE Trans. on Robotics, 23(1):60-72, February 2007
*/
doc/additionalDoc/signal.h 0 → 100644
View file @ 2e7a70d5
/**
\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
*/