This page discusses several questions that are often asked by our users.
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 benchmark page.
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:
impl_gradient, etc. are
virtual functions, hence their call is slightly slower than with
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.
main function Callee Map
KCacheGrind displays the Callee Map of the
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),
The two large blocks are calls to
ql0002_. This function is internal to the solver
used in this case (CFSQP) and does not call any code from
RobOptim. Click to enlarge the picture.
array_to_vector, it only represents 0.42% of the
total execution time.
indicating that problem definition in RobOptim is reasonably
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.
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
-DNDEBUG -O3). 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 solvers page and look for stable,
mature solver bridges.
This is actually libltdl's default error message, for instance:
libltdl failed to load plug-in ``roboptim-core-plugin-xxx'': file not found
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
LD_LIBRARY_PATH (or the equivalent for your
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 (
LD_DEBUG=all ./your_executable on Linux).
This will generate a massive quantity of output. Redirect it to a file,
open your favorite editor, and start looking for messages like "symbol lookup
error: undefined symbol...". This may help pinpoint the actual problem.
Most of our tests are implemented generically for both dense and sparse
matrices. Since we rely on Boost.Test, you can use the
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.
The easiest way is to use wilcards, for instance:
Note that depending on your shell, you may need to escape the wildcards: