Gsoc Ideas

Orocos developers and potential mentors can write down their ideas for students here. These are merely suggestions, the student can propose alternatives and needs to work them fully out.

BFL ideas

These are ideas for extending BFL. Ideas can be combined, extended, ...

  • BFL visualization software
BFL provides stable code for Bayesian filtering (Kalman filters, particle filters, histogram filters, ...). BFL however lacks easy visualization of the obtained filter results. We believe that user-friendly visualization software will give a boost to the BFL community. The developed software could offer on-line visualization of probability density functions and link the obtained filter results to a 3D simulation software (providing a model of the scene including estimated objects, robots, ...). As a mere suggestion we mention CLAM ( Main CLAM embodies concepts such as Processing, Port, Control, Configuration... making it possible candidate for visualization. CLAM also offers graphical tools to build full applications without coding. Another suggestion is Blender ( In the past we made some ad-hoc on-line Blender visualization of people tracking (see:
It's your task to evaluate and select a tool or multiple tools for on-line visualization and demonstrate that it is suited for on-line of BFL filtering results.
Requirements: Basic C++ knowledge,.
Willing to learn: BFL/CLAM?/Blender? tools,.
Results: BFL visualization software which offers real-time visualization of BFL filtering results.
Mentors: Tinne De Laet, Herman Bruyninckx
  • Continuous Integration
As many other projects, BFL can be configured in various ways (different Matrix libraries, different RNGs, different OS-es, different compilers or compilation options, using ginac or not, ...). This results in an enormous number of possible combinations and makes it sometimes very hard to estimate the impact of changes in the source code. A continuous integration system would allow to detect regressions far earlier and produce stable "first time right" releases. Furthermore, automatic testing would allow the contributors to easily check the impact on the performance of their commits.
It's your task to set-up a continuous integration system for BFL.
Requirements: Basic C++ knowledge.
Results: Continuous integration system for BFL.
Mentors: Tinne De Laet
  • OCL filter components
The Orocos Component Library offers components showing users how Orocos RTT, KDL And BFL can be used. Currently we lack good OCL components for the BFL filters showing best-practice to construct BFL filter components. These OCL components would construct a BFL filter, configure its properties, run the filter and make the results available through dataports. Such components allow easy integration of BFL estimators in Orocos applications. The obtained components should be well documented such that they are useful for Orocos-users.
It's your task to construct OCL components offering BFL estimation functionality.
Requirements: Basic C++ knowledge.
Results: Well tested and documented Orocos components of common BFL filters.
Mentors: Tinne De Laet, Ruben Smits
  • Extend BFL functionality
BFL currently provides stable, basic functionality for Bayesian filtering. Different suggestions are possible to extend BFL functionality:
It's your task to extend BFL estimation functionality.
Requirements: Basic C++ knowledge.
Results: Extra BFL functionality
Mentors: Tinne De Laet
  • Evaluate and redesign BFL/KDL matrix and RNG (Random Number Generator) support
BFL's performance is currently (mainly) limited by the matrix library and random number generators used. BFL offers a matrix wrapper for boost, LTI and Newmat and a RNG wrapper for boost, LTI and Scythe. The matrix libraries offer no real-time matrix calculations and are far from allocation-free. Performance of the RNG libraries remains to be studied. Equipping BFL with a fast, allocation-free matrix library and random number generator will boost its performance. As a mere suggestion we mention Eigen2, a very promising fast and versatile matrix library.
It's your task to equip BFL with a fast, allocation-free matrix library and random number generator and show their performance gain.
Requirements: Basic C++ knowledge.
Results: Towards real-time filtering through the use of a allocation-free matrix library and random number generator.
Mentors: Tinne De Laet, Ruben Smits

KDL ideas

These are ideas for extending KDL. Ideas can be combined, extended, ...

This project will look to what extend KDL can use Eigen2 in its different modules. Eigen2 is a very promising fast and versatile matrix library, already used by other big open source projects such as KDE. Especially the kinematic module should be ported from boost::ublas to Eigen2 since it already shown that Eigen2 has better performance. For the kinetostatic module porting should be evaluated in terms of performance of all the operations on the module before full porting is considered. The BFL project has a similar proposal: BFL Ideas
  • Realistic dynamics simulation of human motion
This project creates a (configurable) set of human skeleton models, adding realistic values of joint ranges, inertias, etc., and implements the solvers for forward and inverse dynamics. These algorithms are well described in the robotics literature, and some reference implementations are available. These implementations however do not comply with the realtime requirements that Orocos wants to achieve in (most of) its solvers, so specific attention has to be paid in this respect.
  • Construction of set of realistic gaits
This project is complementary to the previous one, in that it creates nominal motion patterns for humanoid kinematic chains: walking (at different speeds), reaching, running, etc. This work involves appropriate combinations of constraints on the humanoid skeletons' joint space and Cartesian space motion degrees of freedom, the selection of appropriate balance and motion control algorithms, and the specification of relevant task primitives.
  • Adding mobile platform kinematic chains
This project adds the most common kinematic chains of mobile robots to KDL: car and bicycle like kinematics; differentially driven kinematics; truck-and-trailer kinematics; etc. It also provides support for appropriate elementary motion profiles for such devices, including both instantaneous motion commands and non-instantaneous trajectories.

Requirements: Basic C++ knowledge, robot kinematics.

Willing to learn: KDL, kinematics and dynamics solvers.

Results: realistic simulation of human and mobile platform motion (instantaneous motion as well as non-instantaneous "trajectories").

Mentors: Herman Bruyninckx, Ruben Smits

OCL Ideas

These are ideas for writing or extending Orocos components.

  • Write a KDE, GNOME or FLTK component interfacing application
Each Orocos component has a fixed set of primitives: properties, methods, data ports and so on. When interfacing with a component, one wants to see or set these values or call specific methods. In this way, for each component, a GUI could be drawn which represents these relevant facets. There are tools like QT Designer, Glade or FLTK/FLUID which allow to draw such an interface in a matter of hours and produce an XML file which allows to redraw it from any application. Here comes the magic trick: if this application understands the XML format and can 'talk to' Orocos components, it can link the GUI elements (like buttons, displays etc) to the component's interface. Orocos components already provide a dynamic scripting interface which allows run-time interaction (take a look at the OCL TaskBrowser for an example).
It's your task to evaluate and select a tool and demonstrate that it can create GUI's for components. Next write an Orocos application that reads such a GUI description and 'links' it to a given component interface.
Requirements: Basic C++ knowledge,
Willing to learn: KDE/GNOME/FLTK GUI tools,
Results: a stand-alone application that reads an XML file, loads an Orocos component and connects some GUI elements to the component interface.
Mentors: Peter Soetens
  • Unified OpenCV support
Image processing components have become one of the most written components in OCL. Several people have proposed implementations. It's your task to evaluate, test and improve them.
Requirements: Basic C++ knowledge, a digital (firewire or usb) camera, be very interactive on the Orocos-dev mailinglist during your work
Willing to learn: Orocos component building and OpenCV
Results: The result should be a collection of OCL components for image processing which is acceptable for many applications.
  • Create a command line toolset to query and call components.
Today, most if not all Orocos components are commanded from within the TaskBrowser component, which is a read-line based interface to the scripting interface of the component. This doesn't allow much automation from shell scripts or external applications. It's your task to write tiny C++ programs that take some arguments and allow to query or set parameters of a component. Your program will use the RTT CORBA interface behind the scenes to communicate with any registered component. We're aiming for full inspection of the component interface: properties, data ports, commands, methods and events.
Requirements: Basic C++ knowledge,
Willing to learn: RTT CORBA interface
Results: a set of command line tools that take simple arguments and invoke a component method or return the result of a component query.
Mentors: Peter Soetens
  • Create a GUI for basic code generation for component builders
Today, the component builder has to write all the code for his new components. Your task will be to generate a GUI in which the component builder can draw class-like component diagram in which all components (and their methods, commands, properties) and the connection between the components are indicated. Your program will subsequently translate this class-like diagram to C++ code for all the components and xml code for the deployer (taking care of connecting components, ... ). Such a tool would certainly make component building easier and would also increase speed of component building.
Requirements: Basic C++ knowledge,
Willing to learn: Basix xml code, OCL Component building, GUI tools,
Results: a tool translating a GUI class-like component diagram to C++ code for components and xml code for deployer
Mentors: Ruben Smits, Tinne De Laet

RTT Ideas

This wiki pages collects ideas for student assignments for extending the RTT. Feel free to add your own, or add yourself as mentor.

  • Improve the Thread creation and management layer
The RTT creates threads behind the scenes for executing user code. Today you can create two kinds of thread objects: for periodic (PeriodicThread) and non periodic (SingleThread) execution. There is no real reason why this is necessary. It's your task to create a Thread class which can be given a period (and then becomes periodic) but can be made non periodic on the fly as well. Thread is an internal RTT class. So also write the new Activity class (which replaces PeriodicActivity and NonPeriodicActivity). In addition extend the Thread API such that one can set stack size (if the OS supports it) and change the priority and/or scheduler.
Requirements: Basic knowledge of C++, basic knowledge of version control (svn,git,..)
Willing to learn: Thread behavior of various real-time Operating Systems (Linux, Xenomai, RTAI,...), how the RTT executes stuff
Results: patches for RTT, documentation
Links:,, CoreLib Activities, RTT OS Abstration, OS API Reference
Mentors: Peter Soetens
  • Performance evaluation and development of a standard benchmark and regression testing suite for OROCOS
Up to date OROCOS has not been put through a solid performance analysis in order to answer the following questions: what are the additional latencies/overhead introduced by the framework compared to bare metal XENOMAI or RT Preempt? What are the worst case latencies to be expected? What is the computational overhead? What is the memory footprint?
There are a plethora of tools around for this such as oprofile, gcov, gprof, ftrace, SystemTap only to name a few. The goals of this project are to develop one or more test applications and finding answers to the above questions. Secondly the test applications shall be turned into a more general and extensible benchmarking framework suitable for continuous regression testing. Optionally if any obvious performance "hot-spots" (the "low-hanging fruit") are identified these may be fixed with help of the community.
Requirements: some knowledge of C/C++, high level understanding of CPU architectures, familiarity with Linux, some higher level language like Perl/Python/Ruby/...
Willing to learn: Linux internals, real-time concepts, Linux tools, git
Results: results of performance measurement, test framework
Mentors: Markus Klotzbuecher, Peter Soetens