Release Schedule

  • updated plan at 30/03
    • possible backports: #128, port proxy leaking log files, #131, #143
    • showstoppers:
    • add news on the main page
    • have a look through the documentation
    • build videos
    • checking tutorials: use next, start from a fresh bootstrap
      • Felix: Basics Introduction => Installing Packages => pushed doc changes to master
      • Alex: Viewing the data
      • Janosch,Sylvain: finding the right widget: integrate vizkit + manifest-based widget crawler
      • Felix: remove "how to load configuration" => move it to "Configure components". Use TaskContext#apply_conf_file (rename TaskContext#load_conf to TaskContext#apply_conf_file) => pushed code changes to next, documentation changes to master
      • Sylvain: Introduction, Deployments
      • Alex: Replaying data => Create Qt Designer
      • Alex: rename Data Visualization to Vizkit Basics and 3D Data Visualization to Vizkit 3D Display
      • Sylvain: describe propery logging in "Logging and replay", describe oroconf logextract
      • Sylvain: move avahi tutorial at the end
      • Sylvain: rewrite 3D vizkit plugins to Ruby, integrate in "Writing a 3D Vizkit visualizer", renamed to "Writing a 3D Vizkit Plugin". Tell Javier
      • Javier: Data Visualization => interface 3D vizkit plugins to ruby. Check ticket#68 Verified Basic tutorial related to ticket#68 which are: Simulate a Robot Adding a Joystick and Virtual Joystick
      • Thomas: System Management tutorials
      • Sylvain: remove bundle documentation ?

Old release schedule

  • at 22/08
    • push next => stable
  • up until the build server is back online
    • update xsens to new frame convention
    • update gps to new frame convention
    • publish new packages out of spacegit
    • add status page to the rock website
    • show update logs on website
    • show "commits since XXX" on website
  • when the build server is back online (T0)
    • 1 week "push" period (update next)
  • T0 + 1 week
    • 2 week testing phase starts
  • T0 + 3 week
    • prerelease: base system (drivers, toolchain, some packages like envire)
    • and beer (or stronger)
  • 15/10
    • everything else
    • release


Will have to be done before the release

  • [Sylvain] base/types/cmake => base/cmake
  • "systems using Rock" page => detailed examples / use cases
    • [Jakob] need clearing it with DFKI management
  • publish a small camera log file
    • [Marc] underwater car logfile ~10M uncompressed
    • [Sylvain] compress it using pocolog
    • [Jan] add it to the gitorious code => goes on gitorious
  • [Sylvain] publish the new rock.base with updated master/next/stable
  • [Sylvain] check the body frame convention in code that should be released
    • gps
    • xsens_imu (follows Xsens frame printed on the device)
  • [Jan] scripts in orogen components
    • need a guideline
    • embed in tutorials
  • manifest.xml > what policy on using depend vs. rosdep
    • make a guideline out of it
  • move packages from spacegit => gitorious [see list below]
  • documentation / tutorials / examples on specific "issues"
    • how to write a device driver
    • documentation on taskmon (top-like visualization ?)



  • publishing
    • putting the package on gitorious, following the package structure / naming convention
    • adding the package to the rock package set
    • check for body frame convention
    • announce it on rock-dev
  • Marc: orientation estimator (xsens / fog integration)
  • Marc: pose estimator based on accelerometer data
  • Thomas: fipa stuff
  • Thomas: polygon net
  • Thomas: Gumstix camera driver
  • Matthias: tritech sonar drivers (micron,profiling) => check for Gemini
  • Matthias/Javier: fog driver
  • Matthias: v4l camera driver
  • Sylvain: firewire camera driver
  • Chris M: unicap camera
  • Sylvain/Patrick: API documentation for pose_ekf
  • Matthias: driver for the iCharger
  • Marc: DesertStar pressure sensor
  • Marc: DesertStar modem
  • Marc: DesertStar LBL
  • Marc: Teledyne Explorer DVL
  • Jakob/Marc: stereovision
  • Sylvain: revert back to "plain" libelas
  • Marc: SurfGPU
  • Matthias: BlueView ? Need to find a maintainer, problem with downloading the SDK


  • add license, display it on




  • N: not in release
  • Y: in release, already on and ready
  • TBD: needs action before release
  • >: delayed to next release
Y planning/orogen/corridor_navigation
Y base/orogen/types
Y base/scripts
Y base/types
Y drivers/hokuyo
Y drivers/iodrivers_base
Y drivers/orogen/canbus
Y drivers/orogen/dynamixel
Y drivers/orogen/gps
Y drivers/orogen/hokuyo
Y drivers/orogen/parport
Y redistribution accepted by Vicon drivers/orogen/vicon
Y drivers/orogen/wifimon
Y redistribution accepted by Xsens drivers/orogen/xsens_imu
Y drivers/parport
Y redistribution accepted by vicon drivers/vicon
Y redistribution accepted by Xsens drivers/xsens_imu
Y external/libply
Y external/sisl
Y external/yaml-cpp
Y gui/vizkit
Y image_processing/frame_helper
Y control/orogen/skid4_control
Y control/orogen/trajectory_follower
Y control/orogen/waypoint_navigation
Y control/trajectory_follower
Y control/waypoint_navigation
Y drivers/camera_interface
Y drivers/canbus
Y drivers/dynamixel
Y image_processing/video_writer
Y orogen
Y planning/corridor_planner
Y planning/orogen/corridor_planner
Y planning/vfh_star
Y rtt
Y slam/envire
Y documentation ? slam/pose_ekf
Y tools/roby
Y typelib
Y utilmm
Y utilrb
Y tools/orocos.rb
Y tools/pocolog
TBD roby integration. Move into tools ? drivers/transformer
TBD Code Cleanup missing (review branch created) drivers/tritech_sonar
TBD Code Cleanup missing (review branch created) drivers/orogen/tritech_sonar
TBD Code Cleanup missing (review branch created) drivers/dsp3000
TBD Code Cleanup missing (review branch created) drivers/orogen/dsp3000
TBD pending transformer integration asguard/orogen/icp
TBD simplification of asguard/orogen/odometry for simple skid steering systems asguard/orogen/odometry
TBD extraction of common data service/task models from asguard/supervision base/supervision_models
TBD move into tools, documentation, orocos.rb integration communication/service-discovery
TBD rename to simple_controllers, integrate PID class from avalon control/motor_controller
TBD rename to ?stream_sync?, move to tools drivers/aggregator
TBD check license: no license issue drivers/camera_gumstix
TBD clarify on license drivers/camera_prosilica
TBD remove sliderbox (DFKI specific), rename to ?input_dev? drivers/controldev
TBD clarify license drivers/gemini_sonar
TBD move to tools/orogen/logger tools/logger
TBD rename to gps_mb500 drivers/mb500
TBD pending drivers/camera_prosilica drivers/orogen/camera_prosilica
TBD rename ?input_dev? (same as drivers/), document CAN protocol drivers/orogen/controldev
TBD pending drivers/gemini_sonar drivers/orogen/gemini_sonar
TBD pending drivers/camera_gumstix, move to drivers/orogen image_processing/orogen/camera_gumstix
C ? image_processing/experimental_image_processor NOTE ideally rename
C ? image_processing/orogen/experimental_image_processor
> simulation/mars NOTE Maltes call, not in first release
> simulation/orogen/mars-core
TBD be more detailed Gui stuff
TBD needs to be feature-parity with prosilica (common task interface) firewire camera
N DFKI HW asguard/asguard
N DFKI HW asguard/eslam
N DFKI HW asguard/hysteresis_model
N DFKI HW asguard/orogen/asguard_deployment
N DFKI HW asguard/orogen/control
N DFKI HW asguard/orogen/eslam
N DFKI HW asguard/orogen/odometry NOTE simple skid steering model required
N DFKI HW asguard/orogen/pose_estimator
N DFKI HW asguard/orogen/sysmon
N DFKI HW asguard/supervision
N no toolchain integration communication/communication-wrapper
N no toolchain integration communication/fipa-conversation-monitor
C ? communication/fipa_acl
N no toolchain integration drivers/monster_interface
N no toolchain integration drivers/orogen/monster_interface
N no toolchain integration communication/monster-interface NOTE move into drivers
N no toolchain integration communication/orogen/monster-interface NOTE move into drivers
N no toolchain integration communication/orogen/mta
N no toolchain integration communication/orogen/root
N DFKI HW crex/orogen/crex
N ? csurvey/image_classifier
N ? csurvey/laser_control_widget
N ? csurvey/laser_driver
N ? csurvey/orogen/deployments
N ? csurvey/orogen/laser_control
N ? csurvey/run_scripts
N DFKI HW drivers/canserial
N DFKI HW drivers/hbridge
N DFKI HW drivers/orogen/canserial
N DFKI HW drivers/orogen/hbridge
C ? external/tinyxml NOTE try using tar.gz from website
N project specific famos/astrium-proxy
N project specific famos/command-parser
N project specific famos/orogen/astriumproxy
N project specific famos/subsystem-interface
N project specific famos/system-core
N project specific famos/system-state
N ? image_processing/orogen/frame_demultiplexer
N ? image_processing/orogen/structured_light
N ? image_processing/structured_light
N DFKI HW sherpa/orogen/sherpa
N project specific simulation/mars-plugins/CrexPlugin
N project specific simulation/mars-plugins/RimresEnv
N move to package heap, rename message-logger, sqlite-logger ? tools/datalogger
N project specific tools/log4cxx-wrapper
N tools/octave
N tools/prog-conf


  • vizkit-ruby (usage and widget development)
  • stream aligner (C++ and orogen plugin)
  • transformer (C++ and orogen plugin)
  • transformer (roby usage)
  • corridor navigation

Aims and goals

Here is the draft of the "aims and goals" text we agreed should be stated upfront on the rock main page

Edit, update, add comments at will ;-)

Rock is a software framework for the development of robotic systems. The underlying component model is based on the Orocos RTT (Real Time Toolkit). Rock provides all the tools required to set up and run high-performance and reliable robotic systems for wide variety of applications in research and industry. It contains a rich collection of ready to use drivers and modules for use in your own system, and can easily be extended by adding new components. The framework was developed to specifically address the following issues in existing solutions:

  • sustainable systems. The architecture and the tools in Rock are designed with long-living systems in mind. In practice, it means that for us, error detection, reporting and handling is key in any robotic architecture.
  • scalability. Provide the tools to be able to manage big systems with a minimum fuss. But we don't require you to learn about these (complex) tools right away: as soon as you use rock's component development tool, oroGen, you have the guarantee that your components can be integrated from simple scenarios using hardcoded C++ behaviours, to Ruby scripts up to the complete system monitoring tools.
  • reusable codebase. Even though we think that the rock toolchain is one of the best out there, some other people might feel differently. And they might be right. That's why, in rock, most of the functionality -- from control to data display through data processing -- is implemented in a way that is totally independent from rock's integration framework. That's right: just pick our drivers, localization algorithms and control loops and integrate them in your integration framework. You don't have to do anything on our side, as the code is completely independent from the integration parts.
Last modified 9 years ago Last modified on 05/02/12 16:51:52