Frequently Asked Questions (FAQ)

This page discusses several questions that are often asked by our users.

Can I use RobOptim for problems that have nothing to do with robotics?

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.

Is using RobOptim slower than implementing directly my problem?

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:

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 Ref feature.
impl_compute, impl_gradient, etc. are virtual functions, hence their call is slightly slower than with non-virtual functions.
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.

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.

Example: profiling of Inverse Kinematics problem resolution through optimization

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.

kcachegrind screenshot Callee Map of the main function

`main` function Callee Map

KCacheGrind displays the Callee Map of the main 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.

The two large blocks are calls to the 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.

Time spent in each function

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.
The most time consuming RobOptim related function is array_to_vector, it only represents 0.42% of the total execution time.
99% of the time is spent in the solve function indicating that problem definition in RobOptim is reasonably efficient.

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 project (i.e. -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.

RobOptim reports that the plug-in could not be found. How can I solve this?

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 operating system).

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.

How can I run one of the tests for dense (or sparse) matrices only?

Most of our tests are implemented generically for both dense and sparse matrices. Since we rely on Boost.Test, you can use the --run_test 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:

./tests/function-constant --run_test=*Dense*

Note that depending on your shell, you may need to escape the wildcards:

./tests/function-constant --run_test=\*Dense\*