Roadmap

Where things are going, and how we plan to get there.

See also Roadmap ideas 3x for some really long-term ideas ...

TODO Autoproj, RTT, OCL, etc.

Real-time logging

The goal is to provide a real-time safe, low overhead, flexbible logging system useable throughout an entire system (ie within both components and any user applications, like GUIs).

We chose to base this on log4cpp, one of the C++-based derivates of log4j, the respected Java logging system. With only minor customimzations log4cpp is now useable in user component code (but not RTT code itself, see below). It provides real-time safe, hierarchical logging with multiple levels of logging (e.g. INFO vs DEBUG).

Near future

  • Provide a complete system example demonstrating use of the real-time logging framework in both user components, and a GUI-based application. Based on the v2 toolchain.
  • Provide a component-based appender demonstrating transport of logging events. Most likely demonstrate centralized logging of a distributed system.
  • Add logging system stress tests. (l already have this for v1, but need to port to v2 and submit)
  • Able have multiple appenders per category. This is simply a technical limitation of the initial approach, and should be readily changeable.

Long term plans

  • Replace the existing RTT::Logger functionality with the real-time logging framework. This really can't involve rewriting all the logging statements in RTT, etc.
  • Provide levels of DEBUG logging. Some logging system use FINE, FINER, FINEST levels, whilst others use DEBUG plus an integer level within debug (e.g. debug-1 thru debug-9, from verbose to most-verbose). Chose one approach, and modify log4cpp to support it.
  • Support use by scripting and state machines (possibly also Lua?). This means both being able to log, as well as being able to configure categories, appenders, etc.

Catkin-ROS build-support plan

Target versions

These changes are for Toolchain >= 2.7.0 + ROS >= Hydro

Goals

Support building in these workflows:

  • Autoproj managed builds (Rock-style)
    • depends on: manifest.xml for meta-build info.
    • Rock users don't use the UseOrocos.cmake macros since their CMakeLists +pc files get generated anyway by orogen.
  • CMake managed builds (every-package-its-own-build-dir-style)
    • depends on: pkg-config files to track linking+includes
    • Uses the UseOrocos.cmake file, autolinking is done by parsing manifest.xml file
  • ROSbuild managed builds
    • depends on: manifest.xml file, rosbuild cmake macros read it and .pc files, Orocos cmake macros read it to link properly (no build flags from manifest file !)
    • Will only be used if the user explicitly called rosbuild_init() in his top-level CMakeLists.txt
  • Catkin managed builds
    • depends on: package.xml file, Orocos generated pkg-config files
    • The Catkin .pc files will be generated but ignored by us (?)
    • No Auto linking
    • We'll also generated .pc files in the devel path during the cmake run

Effects on (Runtime) Environment

  • Deployer's import ?
  • ROS Deb packages ?
  • Orocos Deb packages ?

CMake changes or new macros

  • Auto linking
  • orocos_use_package()
  • orocos_find_package()
  • orocos_generate_package()