[ros-users] ROS Groovy Galapagos Released
Tully Foote
tfoote at willowgarage.com
Tue Jan 1 06:34:34 UTC 2013
[image: Inline image 1]
Hello ROS Community,
As we close out 2012 we're happy to announce the release of ROS Groovy
Galapagos. The theme of this release has been building infrastructure to
support the growing ROS development community.
Using the new rosdistro repository on GitHub as a microcosm, you can get a
sense of scale for the Groovy development There are 118 public forks of
the project publicly available with 73 people having contributed commits to
the repository. Running a script over the history of just the
releases/groovy.yaml file in the repository finds that during the groovy
development cycle there have been over 1100 commits changing the revisions
of packages. And counting each changed version number there have been more
than 3500 releases submitted to be built on the build farm. This means
that there have been more than 10 releases every day for the last 9 months
on average.
These statistics only count the packages which have been converted to use
the new build and release system which currently stands as about half the
released repositories. One of the goals going forward in Hydro development
will be convert the majority of the unconverted packages.
All these releases have been submitted to our upgraded build
farm infrastructure. The over 450 packages are built into binary packages
on 6 different architectures. The binary builds for packages take between
3 and 90 minutes each, and if run on a single computer would take more than
2 weeks to complete running continuously. The automatic documentation jobs
likewise would take several days to run if run on a single computer.
The Groovy release cycle ran longer than originally planned however giving
it the extra development time has allowed us to produce a much more
polished release which will support us better as we start considering how
ROS should progress forward. Going forward the Hydro cycle is expected to
be shortened to bring the releases back into sync with the Ubuntu releases
with a target of Hydro Medusa for April 2013.
In the near future we will begin the Hydro planning cycle and kick off a
new round of SIGs. If you have been thinking about something you would
like to see in ROS the SIGs will be a great opportunities to find others
interested in collaborating to make those thoughts reality.
Below are the Release Notes. They have been filled in for the core
packages and anyone who sent me information has been integrated. If you
have updates stacks or packages, please add your information to the version
on the wiki to make it as complete as possible.
In the final release there have been 82 packages patched since Beta 3.
Most of the focus in the run-up to the release has been on documentation
and tutorials.
Happy New Year!
Your ROS Groovy Release Team
ROS Groovy Galapagos
ROS Groovy Galapagos will be the sixth ROS distribution
release<http://www.ros.org/wiki/Distributions> and
was released December 31st 2012. In this release we have focused on the
core infrastructure of ROS to make it easier to use, more modular, more
scalable, work across a larger number of operating systems/hardware
architectures/robots and most importantly to further involve the ROS
community.
Contents
1. ROS Groovy Galapagos<http://www.ros.org/wiki/groovy#ROS_Groovy_Galapagos>
1. Platforms <http://www.ros.org/wiki/groovy#Platforms>
2. Installation <http://www.ros.org/wiki/groovy#Installation>
3. Major Updates <http://www.ros.org/wiki/groovy#Major_Updates>
1. Mass migration of code to
GitHub<http://www.ros.org/wiki/groovy#Mass_migration_of_code_to_GitHub>
2. New Build System -
catkin<http://www.ros.org/wiki/groovy#New_Build_System_-_catkin>
1. Removal of
Stacks<http://www.ros.org/wiki/groovy#Removal_of_Stacks>
3. New Package Release System -
bloom<http://www.ros.org/wiki/groovy#New_Package_Release_System_-_bloom>
4. New GUI Tools -
rqt<http://www.ros.org/wiki/groovy#New_GUI_Tools_-_rqt>
5. rviz <http://www.ros.org/wiki/groovy#rviz>
6. pluginlib and
class_loader<http://www.ros.org/wiki/groovy#pluginlib_and_class_loader>
7. Gazebo <http://www.ros.org/wiki/groovy#Gazebo>
8. Tutorials <http://www.ros.org/wiki/groovy#Tutorials>
9. Automatic Documentation
Jobs<http://www.ros.org/wiki/groovy#Automatic_Documentation_Jobs>
4. Migrating <http://www.ros.org/wiki/groovy#Migrating>
1. Moving From rosbuild To
catkin<http://www.ros.org/wiki/groovy#Moving_From_rosbuild_To_catkin>
2. Change from Wx to
Qt<http://www.ros.org/wiki/groovy#Change_from_Wx_to_Qt>
3. laser_drivers REP 117 Deprecation
Completed<http://www.ros.org/wiki/groovy#laser_drivers_REP_117_Deprecation_Completed>
5. Change Lists of
Note<http://www.ros.org/wiki/groovy#Change_Lists_of_Note>
6. Plans and Special Interest
Groups<http://www.ros.org/wiki/groovy#Plans_and_Special_Interest_Groups>
1. Sigs <http://www.ros.org/wiki/groovy#Sigs>
2. ROS Enhancement Proposals
(REP)<http://www.ros.org/wiki/groovy#ROS_Enhancement_Proposals_.28REP.29>
Platforms
ROS Groovy Galapagos will be primarily targeted at the Ubuntu 12.04
(Precise) release, though compatibility with other Linux systems as well as
Mac OS X, Android, and Windows is anticipated. For more information on
compatibility, please see REP 3: Target
Platforms<http://ros.org/reps/rep-0003.html>
.
Installation
Please see the installation
instructions<http://www.ros.org/wiki/groovy/Installation>.
There are binary packages available for Ubuntu distributions, Oneiric,
Precise, and Quantal for both 32 and 64 bit architectures. There is also
improved infrastructure for building from source, most heavily tested on
OSX. And experimental instructions for other platforms.
Ubuntu Users: Please make sure to use the Python tools from apt and not
pip. The pip based installs tend to go out of date and not get updated with
the rest of the system.
Major Updates
Mass migration of code to GitHub
Traditionally, ROS code has been scattered across numerous version control
systems (git, svn, hg, etc) across different hosting services throughout
the world. Though the ROS wiki has acted as a central point of
documentation, issue/ticket tracking has been just as disparate as the
usage of VCS tools.
With ROS Groovy, an effort has been made to move core packages to
GitHub<http://github.com/> along
with all issue tracking. This has brought several benefits including making
ROS more available to the wider open source community and providing VCS
consistency for ROS packages. Most importantly, utilizing GitHub has
involved the ROS community more and given it more ownership of the
codebase. GitHub's pull requests have made it much easier for the core ROS
development team to apply patches from the community as well as respond to
design feedback more rapidly. In the last development cycle there have been
71 people who have contributed to the rosdistro file, using 239 pull
requests and there exist 115 public forks of the rosdistro project on
GitHub. The ease of forking and submitting pull requests has made this
higher level of community engagement possible. GitHub additionally provides
excellent tools for navigating code, managing issues/milestones, and
increasing developer communication. All ROS package developers are highly
encouraged, but not required, to utilize GitHub for their own repositories
so as to further unify both the ROS codebase and community.
On GitHub, ROS repositories are spread across several GitHub
"organizations" to group related repositories in an intuitive manner:
-
ROS Infrastructure <https://github.com/ros-infrastructure> - *Foundational
tools for ROS ecosystem such as package release
(bloom<http://www.ros.org/wiki/bloom>),
build farm scripts, documentation generators. Most of these are backend,
non-user facing repositories.*
-
ROS Core <https://github.com/ros> - *Core ROS libraries and tools such
as standard messages, the build system
catkin<http://www.ros.org/wiki/catkin>,
the ROS clientsroscpp <http://www.ros.org/wiki/roscpp> and
rospy<http://www.ros.org/wiki/rospy>
, actionlib <http://www.ros.org/wiki/actionlib>,
pluginlib<http://www.ros.org/wiki/pluginlib>
, nodelet <http://www.ros.org/wiki/nodelet>, etc*
-
ROS Visualization <https://github.com/ros-visualization> - *Graphical
tools to visualize data including rviz <http://www.ros.org/wiki/rviz>
and rqt <http://www.ros.org/wiki/rqt>.*
-
ROS Perception <https://github.com/ros-perception> - *Tools for
perception and vision*
-
ROS Drivers <https://github.com/ros-drivers> - *Drivers for sensors and
other hardware*
-
ROS Drivers <https://github.com/ros-planning> - *Navigation and path
planning related packages including
navigation<http://www.ros.org/wiki/navigation>
and moveit <http://www.ros.org/wiki/moveit>*
New Build System - catkin
The most striking and significant change in Groovy is the introduction of a
new build system called catkin <http://www.ros.org/wiki/catkin> which will
eventually fully replace the original
rosbuild<http://www.ros.org/wiki/rosbuild> build
system. catkin <http://www.ros.org/wiki/catkin> was developed to address
several drawbacks inrosbuild <http://www.ros.org/wiki/rosbuild> so that ROS
can continue to grow and scale. As opposed to rosbuild
catkin<http://www.ros.org/wiki/catkin> promotes
Filesystem Hierarchy Standard (FHS) compliance, making it much easier to
distribute ROS packages on other operating systems and architectures.
Though a prototype version was already introduced in
fuerte<http://www.ros.org/wiki/fuerte> for
a only few packages, catkin is now the official build system of ROS.
rosbuild <http://www.ros.org/wiki/rosbuild> will continue to be supported
for the forseeable future, but in time will be deprecated. catkin has been
designed to be backwards compatible with existing
rosbuild<http://www.ros.org/wiki/rosbuild> packages
and stacks that have not yet migrated. Most of the core packages have
already been migrated and new packages should utilize
catkin<http://www.ros.org/wiki/catkin>
.
The workflow of catkin <http://www.ros.org/wiki/catkin> is somewhat
different from rosbuild <http://www.ros.org/wiki/rosbuild>, but great care
has been taken to make the transition as smooth as possible. Here are some
resources for getting started with catkin <http://www.ros.org/wiki/catkin>:
-
catkin <http://www.ros.org/wiki/catkin> - *Main wiki page*
-
catkin/conceptual_overview<http://www.ros.org/wiki/catkin/conceptual_overview>
- *Reasoning behind the move from rosbuild to catkin*
-
catkin/Tutorials <http://www.ros.org/wiki/catkin/Tutorials> - *Tutorials*
-
catkin/migrating_from_rosbuild<http://www.ros.org/wiki/catkin/migrating_from_rosbuild>
- *Migrating from rosbuild to catkin*
Removal of Stacks
With the new version of catkin in Groovy, the concept of Stacks has been
removed. One of the main reasons for this was that there was a duplication
of dependency tracking between packages and stacks. Previously packages
only depend on packages, and stacks only depend on stacks, so the stack
which contains a package must depend on all of the stacks which contain the
dependencies of that package. Additionally, by removing stacks the code
base has become more modular because you can install any package and its
dependencies, where as in the past a package would often unnecessarily pull
in its stack and other unused dependencies.
To preserve some of the benefits of stack, the concept of "metapackages"
replaces the concept of stacks. A metapackage is not a container of
packages like rosbuild stacks were, but a named set of references to
packages. It can be used to preserve some structure using a catkin
metapackage replacing an old rosbuild stacks (this helps with for backwards
compatibility of documentation with rosbuild, e.g. in wikis). A metapackage
can depend on packages which don't necessarily reside in the same folder or
source repository. This allows for more flexibility of development
workflows, allowing to have separate repositories for packages that
belonged to a single stack.
This is captured more formally in REP 127<http://ros.org/reps/rep-0127.html>
New Package Release System - bloom
With catkin also comes a new package release system known as
bloom<http://www.ros.org/wiki/bloom>
. bloom <http://www.ros.org/wiki/bloom> not only simplifies your workflow
when releasing ROS packages to the world, but also provides features to
make it easier to maintain released packages, version them, and
patch/backport changes.
bloom <http://www.ros.org/wiki/bloom> takes your catkin packages and
releases them to a "release repository". All of the ROS release
repositories are hosted in the ros-gbp organization on https://github.com:
https://github.com/ros-gbp. The release repository contains snapshots of
your source repository (the repository you develop on) and provides tags to
the snapshots. Additionally it creates a "release" branch for each package
in your upstream repository on which you can make patches and it provides
tags for each released version of your packages. Finally,
bloom<http://www.ros.org/wiki/bloom> can
generate files for building Debian .debs on the ROS build farm. Because we
host our release repositories on https://github.com, there are known urls
for each release of each package. This makes the release repositories a
good source for building released ros packages from source.
bloom <http://www.ros.org/wiki/bloom> allows a source code repository to
contain any number of packages, related or not. The only caveat to having
multiple packages in a single repository is that they must be released with
a common version number, i.e. one release version number per repository.
New GUI Tools - rqt
In Groovy, core ROS GUI tools (rxconsole, rxgraph, etc) have been
significantly refined. These tools have been replaced by a single new tool
called rqt <http://www.ros.org/wiki/rqt>. rqt is a software framework that
implements the various GUI tools in the form of plugins. One can run all
the existing GUI tools as dockable windows within rqt -- even
rviz<http://www.ros.org/wiki/rviz>!
The tools can still run in a traditional standalone method, but
rqt<http://www.ros.org/wiki/rqt> makes
it easier to manage all the various windows on the screen at one moment.
Users can create their own plugins for rqt <http://www.ros.org/wiki/rqt> with
either Python or C++. Over 20 plugins
<http://www.ros.org/wiki/rqt/Plugins> have
already been created and more are slated for development.
rviz
rviz <http://www.ros.org/wiki/rviz> has been significantly redesigned with
a cleaner user interface and and a new plugin API covering all major
functions. RViz is now "on its own" and so can be installed directly (on
Ubuntu for example) as ros-groovy-rviz. It no longer depends on
visualization_common, instead depends directly on standard OS installations
of OGRE, easing compilation from source. Python support has been greatly
expanded, so rviz windows, displays, viewpoints, and tools can all be
manipulated from Python now.
The "save" file format has also changed: it now saves into "*.rviz" files
which are in YAML format, easing manual editing, comparison, and automatic
generation.
pluginlib and class_loader
pluginlib <http://www.ros.org/wiki/pluginlib>, the library for creating
plugins in C++ code, has been almost completely rewritten while retaining
100% backwards compatibility. New features include thread-safety,
simplified API, and true library class introspection.
pluginlib<http://www.ros.org/wiki/pluginlib>is
now built on top of a new ROS-independent package called
class_loader<http://www.ros.org/wiki/class_loader> which
can be used to work with plugins in software that does not utilize the ROS
build system.
Gazebo
The Gazebo simulator project <http://gazebosim.org/>, the simulation engine
used within the simulator_gazebo ros
stack<http://www.ros.org/wiki/simulator_gazebo>,
has recently undergone major improvements and re-factoring as it went
from version
1.0 to 1.3 <http://gazebosim.org/wiki/Change_log>. The Groovy release of
Gazebo <http://www.ros.org/wiki/gazebo> has been updated to run with gazebo
1.2.x <http://gazebosim.org/wiki/Change_log#Gazebo_1.2.6_.282012-11-08.29> with
pending updates to upgrade to gazebo
1.3.x<http://gazebosim.org/wiki/Change_log#Gazebo_1.3.0_.282012-12-03.29>
in
the near future.
All changes in the underlying simulator can be found on gazebosim.org, as
well as commonly asked questions and answers for gazebo via gazebo answers
page <http://answers.gazebosim.org/>.
Other New Packages:
-
depthimage_to_laserscan
<http://www.ros.org/wiki/depthimage_to_laserscan>replaces
pointcloud_to_laserscan
Tutorials
The significant overhaul of core ROS infrastructure has meant a significant
change in fundamental ROS documentation, primarily in the tutorials. It is
recommended to review them again, even if you are a ROS veteran, at
http://www.ros.org/wiki/ROS/Tutorials. All the Tutorials beyond Creating A
Package have been converted to support the new and old build system.
Automatic Documentation Jobs
One of the valuable services provided to the ROS community is the public
indexing of packages and automatic documentation generation onto ros.org.
The entire system has been overhauled to parallelize and isolate failures
of individual repositories from stopping other repositories from being
documented. The new infrastructure now also provides properly versioned
documentation for each ROS distro. For more information on how to be
indexed in the new system see the Get Involved
page.<http://www.ros.org/wiki/Get%2520Involved#Documenting_Your_.2A-ros-pkg_Repository_on_ROS.org>
Migrating
As with any release there have been some areas which will require updating.
In this cycle most of the changes have been adding APIs while maintaining
backwards compatibility for the old APIs.
Moving From rosbuild To catkin
The biggest change is the switch from rosbuild<http://www.ros.org/wiki/rosbuild>
to catkin <http://www.ros.org/wiki/catkin>. This switch has been done
while providing backwards compatibility, such that legacy packages can
depend on converted packages without being changed. However catkin based
packages cannot depend on rosbuild based packages. This leads to what has
been called the rising tide where the conversion to catkin must propogate
up the dependency tree. Wet packages, catkin based, are always below the
dry packages, rosbuild based, as the tide rises.
A detailed guide to converting packages can be found in the catkin
documentation. catkin/migrating_from_rosbuild<http://www.ros.org/wiki/catkin/migrating_from_rosbuild>
Change from Wx to Qt
One significant change is the transition from Wx to Qt. If you have been
using Wx graphical toolkits it is recommended to switch. Most of our
primary visualization tools have been ported to Qt. And there are many
plugins for them. <http://www.ros.org/wiki/rqt/Plugins> There are tutorials
on the [[rqt] page on how to write new Qt based plugins.
laser_drivers REP 117 Deprecation Completed
If you have been using the laser_drivers the changes made by REP 117 have
now become the default option. For more information see REP
117<http://www.ros.org/reps/rep-0117.html>
Change Lists of Note
-
class_loader 0.1.18 <http://www.ros.org/wiki/class_loader/ChangeList>
-
pluginlib 1.9.15 <http://www.ros.org/wiki/pluginlib/ChangeList>
-
rviz 1.9.6 <http://www.ros.org/wiki/rviz/ChangeList/1.9>
-
laser_drivers/ChangeList/1.7<http://www.ros.org/wiki/laser_drivers/ChangeList/1.7>
-
imu_drivers/ChangeList/1.5<http://www.ros.org/wiki/imu_drivers/ChangeList/1.5>
-
common_msgs/ChangeList/1.9<http://www.ros.org/wiki/common_msgs/ChangeList/1.9>
Plans and Special Interest Groups
The planning for the Groovy release was coordinated on the planning
page<http://www.ros.org/wiki/groovy/Planning>
.
Sigs
A significant amount of the Groovy development was coordinated by Special
Interest Groups. These groups are summarized at the bottom of the planning
page <http://www.ros.org/wiki/groovy/Planning#SIGs>.
ROS Enhancement Proposals (REP)
Four REPs have been finalized during the Groovy development cycle:
-
REP 117 Informational Distance
Measurements<http://www.ros.org/reps/rep-0117.html>
-
REP 127 Specification of package manifest
format<http://ros.org/reps/rep-0127.html>
-
REP 128 Naming Conventions for Catkin Based
Workspaces<http://ros.org/reps/rep-0128.html>
-
REP 131 ROS Groovy Variants <http://ros.org/reps/rep-0131.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20121231/6d30e4f1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ellingson_groovygalapagos.jpg
Type: image/jpeg
Size: 177954 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20121231/6d30e4f1/attachment-0003.jpg>
More information about the ros-users
mailing list