-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathfaq.html
185 lines (148 loc) · 7.4 KB
/
faq.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
---
layout: default
title: Frequently Asked Questions (FAQ)
group: "navigation"
disqus: true
---
<h1 id="faq" class="page-header">{{ page.title }}</h1>
<p>This page discusses several questions that are often asked by our
users.</p>
<h2>Can I use RobOptim for problems that have nothing to do with robotics?</h2>
<p>
Even though this project was started with robotics in mind, any
optimization problem can be solved with RobOptim. This library has
been used successfully for bounding volume generation, path planning,
computer vision, posture generation, and it could also be used for any
other kind of constrained nonlinear optimization problems. For
instance, our test suite relies on the Hock-Schittkowski collection,
which contains a large set of generic nonlinear optimization problems.
For more information, check the <a href="benchmark.html">benchmark
page</a>.
</p>
<h2>Is using RobOptim slower than implementing directly my problem?</h2>
<p>RobOptim takes great care to not slow down the optimization
process. However, it greatly depends on the complexity of your
problem: if you have a very small or linear problem, the cost of the
infrastructure may appear. For instance:</p>
<ul>
<li>Copies are made between RobOptim and the underlying solvers for
technical reasons such as memory alignment and Eigen (former)
limitations. Other copies may have to be done to decouple the solver
data from the RobOptim problem. This could be solved in the future
by using Eigen's new <code>Ref</code> feature.</li>
<li><code>impl_compute</code>, <code>impl_gradient</code>, etc. are
virtual functions, hence their call is slightly slower than with
non-virtual functions.</li>
<li>RobOptim stores meta-information about the problem (function
titles, sizes, etc.) and may need to allocate more memory than a
custom-made program. Additional time spent in allocation routines,
cache miss, or loss of memory locality induced by additional
allocation may cause the optimization to run slower in particular
cases. However, stable RobOptim components take great care of never
allocating memory during the optimization process.</li>
</ul>
Additionally, the use of RobOptim operators, logging, finite
differentiation may lead to slow resolution. All these previously
mentioned features are optional and not always provided by solvers.
<h3>Example: profiling of Inverse Kinematics problem resolution
through optimization</h3>
<p>A typical RobOptim application may be to compute the configuration
of a robotic arm so that its end-effector reaches a particular
position in the operational space (Euclidean space). The following
screenshot shows the output of KCacheGrind after solving the problem
100 times for 100 different reachable positions chosen randomly. For
simplicity, the optimization problem is rebuilt from scratch at each
time so that 10000 optimization problems are built in this case.</p>
<hr>
<div class="media">
<a href="assets/faq/kcachegrind1.png" class="pull-right">
<img src="assets/faq/kcachegrind1-mini.png"
alt="kcachegrind screenshot Callee Map of the main function"
class="media-object img-responsive">
</a>
<div class="media-body">
<h4 class="media-heading"><code>main</code> function Callee Map</h4>
<p>KCacheGrind displays the Callee Map of the <code>main</code>
function. On the Callee Map, each function called by the "main"
function is displayed. The area of each box matches the time
spent in each function. Data are generated using Valgrind's
callgrind tool on Ubuntu 12.04 Precise Pangolin (64-bits),
GCC 4.6.3.
</p>
<p>The two large blocks are calls to
the <code>ql0002_</code>. This function is internal to the solver
used in this case (CFSQP) and does not call any code from
RobOptim. <small>Click to enlarge the picture.</small></p>
</div>
</div>
<hr>
<div class="media">
<a href="assets/faq/kcachegrind2.png" class="pull-left">
<img src="assets/faq/kcachegrind2-mini.png"
alt="kcachegrind screenshot time spent in each function"
class="media-object img-responsive">
</a>
<div class="media-body">
<h4 class="media-heading">Time spent in each function</h4>
<ul>
<li>84% of the total execution time is spent in one function of the
solver. RobOptim cannot have any impact on the run-time of this
function as no code from the framework is used at this point. The
remaining 16% gathers problem creation, display, solver
initialization and RobOptim run-time cost.</li>
<li>The most time consuming RobOptim related function
is <code>array_to_vector</code>, it only represents 0.42% of the
total execution time.</li>
<li>99% of the time is spent in the <code>solve</code> function
indicating that problem definition in RobOptim is reasonably
efficient.</li>
</ul>
</div>
</div>
<hr>
<p>Profiling data shows that RobOptim does not decrease optimization
efficiency. The infrastructure code is efficient and rarely
called. The checks are efficiently disabled and optimized out in
release mode. Building the problem may be more efficient without
RobOptim, but is fast enough even when RobOptim is used. Furthermore,
problem building is a one-time cost.</p>
<p>If you experience a lack of efficiency while using RobOptim, make sure
you are compiling in release mode. Binary packages are always built
this way. You should also pass the appropriate flags to your own
project (i.e. <code>-DNDEBUG -O3</code>). Your experience may also
vary depending on the solver you use. Younger, unstable plug-ins may
be slower as they may copy uselessly data around or do not use the
solver API in the most efficient way. Check
the <a href="solvers.html">solvers page</a> and look for stable,
mature solver bridges.</p>
<h2>RobOptim reports that the plug-in could not be found. How can I solve
this?</h2>
<p>This is actually libltdl's default error message, for instance:</p>
<blockquote>
libltdl failed to load plug-in ``roboptim-core-plugin-xxx'': file not found
</blockquote>
<p>Most of the time, it indicates that libltdl could not find the solver plug-in
you were trying to use. Make sure the plug-in is properly installed, and that it
is in your <code>LD_LIBRARY_PATH</code> (or the equivalent for your
operating system).</p>
<p>If this does not solve your problem (i.e. libltdl should find the library
but still reports it as not found), you can enable the dynamic linker's
debug mode (<code>LD_DEBUG=all ./your_executable</code> on Linux).
This will generate a <b>massive</b> quantity of output. Redirect it to a file,
open your favorite editor, and start looking for messages like <i>"symbol lookup
error: undefined symbol..."</i>. This may help pinpoint the actual problem.
</p>
<h2>How can I run one of the tests for dense (or sparse) matrices only?</h2>
<p>Most of our tests are implemented generically for both dense and sparse
matrices. Since we rely on Boost.Test, you can use the <a
href="http://www.boost.org/doc/libs/1_56_0/libs/test/doc/html/utf/user-guide/runtime-config/run-by-name.html"><code>--run_test</code></a>
command-line argument to run specific test units selected by their name.
This provides a simple way to select the kind of tests you want to run.</p>
<p>The easiest way is to use wilcards, for instance:</p>
<blockquote>
./tests/function-constant --run_test=*Dense*
</blockquote>
<p>Note that depending on your shell, you may need to escape the wildcards:</p>
<blockquote>
./tests/function-constant --run_test=\*Dense\*
</blockquote>