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
Showing
with 180 additions and 151 deletions
......@@ -6,13 +6,18 @@ 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.
- 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
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
......
......@@ -13,10 +13,11 @@ 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
\code{.sh}
git clone https://github.com/stack-of-tasks/dynamic-graph.git
\endcode
......
......@@ -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
*/
......@@ -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
......
/**
\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.
*/
/**
/**
\page subp_references References
\section sec_refer References
......@@ -7,7 +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
......
......@@ -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
*/
......@@ -2,16 +2,16 @@
\page tracerrealtimedoc TracerRealTime
\section tracerrealtimedoc_description Description
The \b TracerRealTime entity monitors a set of signals with real-time constraints; its
function is very similar to the Tracer, except that all traces are recorded to a
memory buffer, which can be emptied at any time.
The \b TracerRealTime entity monitors a set of signals with real-time
constraints; its function is very similar to the Tracer, except that all traces
are recorded to a memory buffer, which can be emptied at any time.
\section tracerrealtimedoc_commands Commands
The \b commands that this entity exposes are:
\code
empty (discards all buffers)
buffersize (sets buffer size for recording)
trace (writes traces to files)
getBufferSize (gets buffer size for recording)
setBufferSize (sets buffer size for recording)
\endcode
Plus all the commands exposed by \ref tracerdoc
\n
......
/**
\page tracerdoc Tracer
\section tracerdoc_description Description
The \b Tracer entity monitors a set of signals. With an input change on the entity's [trigger] signal,
the tracked signal values are recorded and traced to a file. The behavior of the trace-to-file
function can be changed, from printing to a file immediately after recording, to printing out
only when asked explicitly.
The \b Tracer entity monitors a set of signals. With an input change on the
entity's [trigger] signal, the tracked signal values are recorded and traced to
a file. The behavior of the trace-to-file function can be changed, from printing
to a file immediately after recording, to printing out only when asked
explicitly.
\section tracerdoc_commands Commands
The \b commands that this entity exposes are:
......@@ -22,22 +23,15 @@ code documentation of the dynamicgraph::Tracer class.
\n\n
\section tracerdoc_sample Sample usage
The following code creates a TracerRealTime entity, then sets the tracing buffer
size to 10MB. It then tells the tracer to create files with names of the form:
jl_XXX.dat where XXX is the signal name, and adds a few signals after
clearing the traces;
The following code creates a TracerRealTime entity and sets the tracing buffer
size to 80MB. It then tells the tracer to create files with names of the form:
/tmp/dg_XXX.dat where XXX is the signal name, and call the signal
after the device has evaluated the control law:
\code
new TracerRealTime tr
tr.bufferSize 10485760
tr.open ${TRACE_REPOSITORY} jl_ .dat
OpenHRP.periodicCall addSignal tr.triger
(...)
# --- TRACE ---
tr.clear
tr.add OpenHRP.forceRARM
tr.add dyn.0
tr.add jgain.gain
robot.tracer = TracerRealTime("com_tracer")
robot.tracer.setBufferSize(80*(2**20))
robot.tracer.open('/tmp','dg_','.dat')
robot.device.after.addSignal('{0}.triger'.format(robot.tracer.name))
\endcode
\section tracerdoc_addi Additional information
......
......@@ -21,6 +21,7 @@ It provides the following output:
\section fromdottojs Viewing in a browser
To view the dot file you can simply use the view_sot_dg.html file.
Click on the "Choose File" to specify the filem and click on "Rendering" to display the graph.
Click on the "Choose File" to specify the filem and click on "Rendering" to
display the graph.
*/
/* Customizing Doxygen output */
/* Needed to allow line breaks in tables*/
.memberdecls {
table-layout: fixed;
width: 100%;
}
/* Needed to break long template names*/
.memTemplItemLeft {
white-space: normal !important;
word-wrap: break-word;
}
/* Needed to break long template names*/
.memItemLeft {
white-space: normal !important;
word-wrap: break-word;
}
<!-- HTML header for doxygen 1.8.11-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen $doxygenversion"/>
<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
<link href="$relpath^sot.ico" rel="icon" type="image/x-icon">
<script type="text/javascript" src="$relpath^jquery.js"></script>
<script type="text/javascript" src="$relpath^dynsections.js"></script>
$treeview
$search
$mathjax
<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
$extrastylesheet
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<!--BEGIN TITLEAREA-->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<!--BEGIN PROJECT_LOGO-->
<td id="projectlogo"><img alt="Logo" src="$relpath^$projectlogo"/></td>
<!--END PROJECT_LOGO-->
<!--BEGIN PROJECT_NAME-->
<td id="projectalign" style="padding-left: 0.5em;">
<div id="projectname">$projectname
<!--BEGIN PROJECT_NUMBER-->&#160;<span id="projectnumber">$projectnumber</span><!--END PROJECT_NUMBER-->
</div>
<!--BEGIN PROJECT_BRIEF--><div id="projectbrief">$projectbrief</div><!--END PROJECT_BRIEF-->
</td>
<!--END PROJECT_NAME-->
<!--BEGIN !PROJECT_NAME-->
<!--BEGIN PROJECT_BRIEF-->
<td style="padding-left: 0.5em;">
<div id="projectbrief">$projectbrief</div>
</td>
<!--END PROJECT_BRIEF-->
<!--END !PROJECT_NAME-->
<!--BEGIN DISABLE_INDEX-->
<!--BEGIN SEARCHENGINE-->
<td>$searchbox</td>
<!--END SEARCHENGINE-->
<!--END DISABLE_INDEX-->
</tr>
</tbody>
</table>
</div>
<!--END TITLEAREA-->
<!-- end header part -->
File moved
......@@ -9,7 +9,7 @@
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
id="svg2"
version="1.1"
inkscape:version="0.47 r22583"
......
doc/pictures/sot.ico

4.98 KiB

doc/pictures/sot.png

2.78 KiB

File moved
SET(${PROJECT_NAME}_HEADERS
fwd.hh
null-ptr.hh
debug.h
real-time-logger.h
dynamic-graph-api.h
entity.h
factory.h
pool.h
exception-abstract.h
exception-factory.h
exception-signal.h
exception-traces.h
signal.h
signal-array.h
signal-base.h
signal-ptr.h
signal-time-dependent.h
signal-ptr.t.cpp
signal.t.cpp
time-dependency.h
time-dependency.t.cpp
signal-caster.h
signal-cast-helper.h
all-signals.h
signal-helper.h
entity-helper.h
tracer.h
tracer-real-time.h
command.h
eigen-io.h
linear-algebra.h
value.h
command-setter.h
command-setter.t.cpp
command-getter.h
command-getter.t.cpp
command-direct-getter.h
command-direct-setter.h
command-bind.h
all-commands.h
logger.h
)
INSTALL(FILES ${${PROJECT_NAME}_HEADERS}
DESTINATION include/${PROJECT_NAME}
)
......@@ -4,7 +4,7 @@
//
#ifndef DYNAMIC_GRAPH_ALL_COMMANDS_H
# define DYNAMIC_GRAPH_ALL_COMMANDS_H
#define DYNAMIC_GRAPH_ALL_COMMANDS_H
// Utility header files including all commands headers
......@@ -12,7 +12,7 @@
#include <dynamic-graph/command-direct-getter.h>
#include <dynamic-graph/command-direct-setter.h>
#include <dynamic-graph/command-getter.h>
#include <dynamic-graph/command.h>
#include <dynamic-graph/command-setter.h>
#include <dynamic-graph/command.h>
#endif //! DYNAMIC_GRAPH_ALL_COMMANDS_H
#endif //! DYNAMIC_GRAPH_ALL_COMMANDS_H