Wiki

Page

User

ROS Diamondback

Diamondback was released on March 2, 2011 and is the third ROS distribution release. It contains over forty new stacks, including support for the Kinect, contributed stacks from growing ROS community, and a stable release of Point Cloud Library. Diamondback has been designed to be smaller, lighter, and more configurable than ROS C Turtle.

Platforms

ROS Diamondback is primarily targeted at the Ubuntu Lucid through Maverick releases, though it can also be installed on various Linux systems like Red Hat, Debian, and Gentoo. It can also be used on OSes like Mac OS X and FreeBSD, though with more limited compatibility.

Variants

Diamondback provides over over 120 ROS stacks. To help you install these stacks more easily, we provide many different variants that organize them by use case and capability. The complete list of common variants is described in REP 108: Diamondback Variants. The main entrypoints for ROS users are:

Overview

Our focus for ROS Diamondback was making ROS smaller and more lightweight to install. We also worked on making ROS more useful with 3D sensors like the Kinect.

ROS refactored

As part of REP 100, ROS was broken into separate pieces: build system (ros), communication system (ros_comm), GUI tools (rx), and documentation tools (documentation).

PCL 0.10

Point Cloud Library is now stable for ROS. Thanks to the many PCL developers that made this possible. PCL was a popular library in the ROS 3D contest and we look forward to ROS users putting it to use with the Kinect and other devices.

Kinect/OpenNI

Kinect and OpenNI libraries for ROS are available in the ni stack. This includes libraries for integrating with pcl, as well as skelton-tracking via NITE. A special thanks goes to Ivan Dryanovski and William Morris, who got the ROS + Kinect ball rolling.

Smaller debs, incremental updates

The binary debian packages are now approximately 50% smaller. New updates to ROS Diamondback will also be smaller as we are now able to offer incremental updates.

GUI vs. non-GUI

In addition to refactoring ROS, we've also reorganized many of the commonly used ROS stacks to separate GUI libraries from core robotics libraries. This means that you can now install libraries like the ROS navigation stack without having to compile heavyweight graphics libraries.

Other major improvements

Eigen 3

The eigen package now supports both Eigen 2 and Eigen 3 APIs. We thank the Eigen community for making this backwards compatibility possible.

The navigation stack can now use the more efficient PointCloud2 type, which is useful with sensor like the Kinect.

rosh, a new Python-based shell environment for ROS

rosh builds on top of IPython to provide common ROS tools, like rostopic and rosservice, but with with the convenience of Pythonic syntax and a Python interpreter. rosh has a relatively stable API but is still under pre-1.0 heavy development.

Release Notes for Stable Stacks

ros 1.4, ros_comm 1.4, rx 1.4, documentation 1.4

Most of the work for this release is described in REP 100, which separated the ROS stack into separate stacks for the build system (ros), communication system (ros_comm), GUI tools (rx), and documentation system (rosdoc).

joystick_drivers 1.4

navigation 1.4

The navigation stack now supports the sensor_msgs/PointCloud2 message which should allow it to be used directly with many PCL filters and nodelets. As a result of this, sensor_msgs/PointCloud support becomes slightly less efficient because a conversion must take place.

Moved the dwa_local_planner from the navigation_experimental stack to the navigation stack. This planner was used by the PR2 during its continuous_ops run and provides nice features like dynamically reconfigurable parameters. The package should have up-to-date documentation on the wiki explaining how things work. Though, its interfaces are very similar to the base_local_planner.

Added the visualize_potential parameter that, along with Ye Cheng's patch, allows the potential area that navfn computes to be visualized in rviz.

Planner now supports a tolerance when making a plan so that if people want to use it to get to a general region, it still work. Say you want to go all the way across the building, but you don't care if you're two feet away from the actual goal point.