The 1st RTT Developers Workshop

Main SponsorMain Sponsor
Place: BARCELONA PAL Robotics offices

Calle Pujades 77-79, 4th floor 4ª 08005 Barcelona, Spain.

See also PAL Robotics

Date: Mo 19th of July - Fr 23 July
1st RTT Developers Workshop


Date Time Topic/Title & Mediator Description
Mon 19/7 9h-13h Big Picture Day

Arriving at PAL offices

Peter shows what 2.0 is and where it is heading
13h-14h Lunch
14h-19h Who're you + plans presentation You made some Impress/Beamer slides and present your work + ideas for future work in < 10 slides.
20h Dinner Opening dinner sponsored by The SourceWorks
Tue 20/7 9h-13h Typekit generation Orogen + message generation.

YARP transport 2.0 (only ports, no methods, events, etc).

Code explosion & extern template solution.

13h-14h Lunch
14h - 19h Component generation Introduction.

What is its place in RTT?

20h Dinner
Wed 21/7 9h-13h Building Fix up RTT/OCL cmake.

Structure of components, repositories and applications (graveyard/attic)

13h-14h Lunch
14h-16h Documentation improvement Structure. Website

Missing part.

Real examples and tutorials Examples. Restructure.

Success stories, who uses

16h Visiting
20h Dinner
Thu 22/7 9h-13h Logging Current status.

Fix architecture.

RTT::Logger remove/replace

13h-14h Lunch
14h-16h Reporting
16h-19h Upgrading from v1 to v2 Describe rtt v2 converter. Caveat document. Try out on user systems.
20h Dinner Closing dinner sponsored by The SourceWorks
Fri 23/7 9h-13h Wrapping-up Day Finishing loose ends, integration and discussions for future work
13h-14h Lunch
14h-17h Wrapping-up Day Finishing loose ends, integration and discussions for future work

If you need or want to provide sponsorship, contact Peter.

Participants - Please add your days of presence !

  • Peter Soetens (Sun 18/7 - Fri 23/7)
    • 19inch all-in-one Core2 system
    • Ubuntu 9.10
  • Sylvain Joyeux
  • Markus Klotzbuecher (Sun 18/7 - Fri 23/7)
    • TP x61
    • Debian Testing
  • Stephen Roderick (Fri 16/7 - Fri 23/7)
    • 15" Mac Book Pro
    • Mac OS X Snow Leopard and Ubuntu Lynx 10.04
  • Charles Lesire-Cabaniols (Mon 19/7 noon - Thu 22/7 8am)
    • Dell Core2 Laptop
    • Ubuntu lucid 10.4
  • Carles Lopez
  • Adolfo Rodriguez Tsouroukdissian (I will be around the whole week)


  • Presentation of participants: how, where and why Orocos is used by others
  • Build system ? Version control ? What web ressources ?
    • DFKI has its own build system ( Mainly standardized on CMake and git.
    • where to put the code and do release management ? (trying out ?)
    • use standard approach for end user build-support files across all sub-projects (ie if CMake, then use the same approach to FindXXX and Config files). Provide example use cases to build against Orocos (ie there is no FindOrocos-XXX.cmake provided by any sub-project, which IMHO is Very Bad for a new user).
  • the components: Orocos has the OCL and DFKI has already open-sourced some components. In what form do we want to distribute them ?
  • the toolchain: where are we going, what are we going to use and lay out a schedule for that.
    • idea from Peter to standardize the type description on the ROS datatypes vs. oroGen's C++ parser
    • component specification is more than datatypes. oroGen
  • release strategy: how to release RTT 2.0 and associated tools. Target date ?
  • integrating new transports
    • YARP transport from Charles
    • ROS transport ? (who would do that ?)
  • Additional maintainers (particularly for OCL)
  • Standardized API's to ease language bindings (eg Python, Java, LISP ... yes, LISP :-) )
  • Integration of dependant packages (e.g. TLSF). Currently (for real-time logging), we have a circular build problem in that RTT needs log4cpp, log4cpp needs TLSF, but TLSF is installed as part of RTT. Big Problem! Peter mentioned integrating log4cpp, but I'm not sure taht this is the best approach (ie long term consequences, keeping up with releases, scalability).
  • Integration of real-time logging from OCL into RTT
    • Use of real-time logging by RTT itself. Transition plan to accomplish this.
  • Clean shutdown semantics (ie allowing state machines and scripts to cleanly shutdown)
  • Scalability of deployment
    • Deploying subsystems/containers/groups of components
    • Parameterizing deployment files (e.g. variable substitution within XML files)