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: http://www.xenomai.org, http://www.rtai.org, 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