Willow Garage Blog

February 11, 2013

Willow Garage has decided to enter the world of commercial opportunities with an eye to becoming a self-sustaining company. This is an important change to our funding model.

The success of the PR2 personal robot and of ROS will continue. There are close to 50 PR2 robots in the world and Willow Garage support of the platform will not diminish. And of course, ROS, as an open source platform, will continue independent of our business model choices. In addition to Willow Garage, its supporters include the Open Source Robotics Foundation and all the other contributors in the ROS community (academic, industrial and individual) who have made it the platform of choice for Robotics.

January 29, 2013

During his sabbatical at Willow Garage, Stéphane Magnenat from the Autonomous Systems Lab, ETH Zurich integrated a new Simultaneous Localization and Mapping (SLAM) solution.  SLAM allows a robot to build a map of its environment, and to localize itself in this map.  This system is based on a modular ICP algorithm, a collaboration with François Pomerleau and Francis Colas at the Autonomous Systems Lab, ETH Zurich.

The ICP is a classical algorithm to find a transformation between two point clouds, representing the same environment but from different viewpoints.  This algorithm forms the basis of most SLAM systems working with laser or depth data.  While the classical ICP algorithm is simple, it does not work well in most real 3D environments, and therefore hundreds of variants have been published in the last 20 years.  These variants address specific problems, but lack a common comparison ground.

The work of Stéphane and his colleagues provides a framework in which different ICP variants can be tested, combined, and evaluated.  The integration with ROS provides a real-time 2D and 3D SLAM system that can fit a large variety of robots and application scenarios without any code change or recompilation.

A paper describing this work will appear in the forthcoming "Autonomous Robots special issue on open source software for robotics research."  A dataset paper proposing a variety of environments along with ground-truth poses was recently published in IJRR (link to http://ijr.sagepub.com/content/31/14/1705.abstract)  (datasets freely available (link to http://projects.asl.ethz.ch/datasets/doku.php?id=laserregistration:laser...)).  The open-source ROS SLAM node is available in the ethzasl_icp_mapping stack (link to http://ros.org/wiki/ethzasl_icp_mapping).

 

January 22, 2013

During his recent internship, Rahul Udasi, an undergraduate student at the University of Waterloo created a motor diagnostic tool for the PR2. The tool allows PR2 users to find motor faults quickly by getting diagnostic data from the motors along with analysis of the collected information. The results are presented in graphs and messages that may indicate what might be wrong with the PR2's joint motors, all without having to remove any covers. 

The first step in the tool is to select which joint motors the users wants to diagnose. Next, the user moves the joints for the specific motors for about 4 seconds to record enough data then moves onto the next joint. For convenience, the PS3 joystick is used to indicate when the user is done with one joint and when to move to the next. After the data is recorded, the user has access to comprehensive logs and analysis of motor performance. If something looks wrong, the software will tell the user where to look for issues with the joint motor. 

By using the tool, users can quickly diagnose motor faults without the need to remove the motors from the assembly, a time-consumering and specialized task. 

For more information please visit the PR2 motor diagnostic page.

January 17, 2013

Stefan Holzer of TU Munich spent last spring working on including new algorithms into the Point Cloud Library (PCL). His main focus was on creating a recognition and machine learning library in PCL. 

With respect to the recognition library, Stefan assisted in implementing LINEMOD [1], a highly efficient template-matching approach for detecting texture-less objects in heavily cluttered scenes. LINEMOD is based on Kinect data. For detecting objects, it uses color gradients computed from image data, as well as surface normals, computed from depth data.

Within the machine learning library, Stefan worked on implementing a flexible and efficient decision tree learning framework. This was applied to obtain keypoint detectors with improved repeatability and efficiency. Additionally, tools were created to evaluate existing detectors and to create the data for learning.

Having a state-of-the-art object detection method in PCL enables efficient detection of texture-less objects with kinect data. Thanks to the new learning framework there is now the ability to create keypoint detectors with improved detection characteristics, which are useful for localization and object detection.

[1] S. Hinterstoisser, S. Holzer, C. Cagniart, S. Ilic, K. Konolige, N. Navab, V. Lepetit Multimodal Templates for Real-Time Detection of Texture-less Objects in Heavily Cluttered Scenes 

IEEE International Conference on Computer

January 15, 2013

Willow Garage would like to congratulate the team behind the Open Motion Planning Library (OMPL), which was recently awarded the grand prize from the Open Source Software World Challenge. The OSSWC is the annual competition hosted by the Ministry of Knowledge and Economy of Korea with the goal of promoting open source software and expanding exchanges among open source software developers all over the world. Fifty-five teams from twenty-three countries participated in this year's competition with OMPL coming out on top.

OMPL is used for motion planning in ROS, as part of the arm navigation stack and as part of the upcoming release of MoveIt!

OMPL is developed and maintained by the Physical and Biological Computing Group at Rice University, led by Dr. Lydia Kavraki. The development is coordinated by Dr. Mark Moll, Dr. Lydia Kavraki (Rice) and Dr. Ioan Șucan.

Willow Garage is proud of our role in supporting OMPL, particularly through the contributions of Dr. Ioan Șucan, Dr. Sachin Chitta and Dr. Gil Jones. The award-winning code is based on an initial version of OMPL written by Ioan Șucan while he was an intern at Willow Garage. Sachin, Gil and Ioan presented aspects of OMPL at ROSCon 2012.

January 11, 2013

During his summer internship at Willow Garage, Julian "Mac" Mason, a Ph.D. candidate from Duke University, worked on the Megaworldmodel: a framework for large-scale, long-term semantic maps.  In constrast to occupancy maps (which model free and occupied space), semantic maps model the location of objects, and (when possible) their identities.  Determining these identities is difficult: object recognition remains an open problem.  For this reason, the Megaworldmodel provides a generic interface to object recognition systems, allowing existing tools to be easily integrated.  Two such tools have already been included: Willow Garage's textured_object_detection, and Hilton Bristow's implementation of Deva Ramanan's deformable-parts model.

The Megaworldmodel cleanly encapsulates the capture, processing, and mapping of recognizable objects, and the querying of the resulting map.  However, not all objects are recognizable! State-of-the-art object recognition algorithms require extensive supervised training to accurately recognize objects.  In large, general environments, manual training is intractable.  There are simply too many objects.  To enable large-scale semantic mapping, the Megaworldmodel includes tools for active object search (using a Kinect-equipped PR2) and for unsupervised object discovery.  While autonomously exploring an environment, the robot will encounter objects (which it cannot yet recognize) from many different viewpoints.  Using unsupervised segmentation, these objects can be detected, and then clustered into training examples for existing object recognition techniques.  Although this does not provide semantic labels (you get "object 6," not "coffee cup"), it does allow object instances to be recognized in other locations, and at other times.  Ongoing work seeks to scale this technique to extremely large datasets, permitting the entirely unsupervised creation of a large object database.

More information about megaworld is available here.

January 8, 2013

   

The ICRA 2013 Mobile Manipulation Challenge

We would like to invite participation in the ICRA 2013 Mobile Manipulation Challenge built around the theme of “Robot’s Kitchen”. Teams are allowed to use their own robots or the PR2 robots that will be provided by the organizers. This is the 2nd year that this challenge is being organized after last year’s “Yesterday’s Sushi” challenge at ICRA 2012 in St. Paul.

Deadline for intent to participate: January 15, 2013
Challenge website: http://mobilemanipulationchallenge.org

Details about the challenge problem, the prizes on offer, registration and qualification details and the preparatory workshop that will be held at Willow Garage in the beginning of March are available on the challenge website.

Looking forward to seeing you at ICRA 2013 in Karlsruhe!

January 1, 2013

 

ellingson_groovygalapagos.jpg

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 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.

 

 

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.

 

Installation

Please see the installation instructions. 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 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:

 

New Build System - catkin

The most striking and significant change in Groovy is the introduction of a new build system called catkin which will eventually fully replace the original rosbuild build system. catkin was developed to address several drawbacks inrosbuild so that ROS can continue to grow and scale. As opposed to rosbuild 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 for a only few packages, catkin is now the official build system of ROS. 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 packages and stacks that have not yet migrated. Most of the core packages have already been migrated and new packages should utilize catkin.

The workflow of catkin is somewhat different from rosbuild, but great care has been taken to make the transition as smooth as possible. Here are some resources for getting started with 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

 

New Package Release System - bloom

With catkin also comes a new package release system known as bloombloom 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 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.comhttps://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 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 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. 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! The tools can still run in a traditional standalone method, but rqt makes it easier to manage all the various windows on the screen at one moment.

Users can create their own plugins for rqt with either Python or C++. Over 20 plugins have already been created and more are slated for development.

 

rviz

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, 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. pluginlibis now built on top of a new ROS-independent package called 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, the simulation engine used within the simulator_gazebo ros stack, has recently undergone major improvements and re-factoring as it went from version 1.0 to 1.3The Groovy release of Gazebo has been updated to run with gazebo 1.2.x with pending updates to upgrade to gazebo 1.3.x 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.

Other New Packages:

 

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.

 

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 to 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

 

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. 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

 

Change Lists of Note

 

Plans and Special Interest Groups

The planning for the Groovy release was coordinated on the planning page.

 

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.

 

ROS Enhancement Proposals (REP)

Four REPs have been finalized during the Groovy development cycle:

 

December 11, 2012

During his internship at Willow Garage, Rob Linsalata from Tufts University worked on running ROS on small, low power ARM-based processors.  Rob focused on driving the TurtleBot around using the TurtleCore -- a small embedded computer produced by Gumstix

Rob worked to integrate the TurtleCore with the TurtleBot throughout his time at Willow Garage.  After initially integrating the TurtleCore and TurtleBot he focused on getting ROS running on the ARM processor in the TurtleCore.  He has provided documentation and procedures to bring up the TurtleCore on the Overo ARM processor.  Rob then helped test and debug ROS functionality running on the ARM architecture.  

The TurtleBot comes by default with an Asus netbook.  The netbook accounts for a significant fraction of the computation, cost, and power consumption when the TurtleBot is operating.  By using a smaller ARM-based processor the TurtleBots can be made to run longer  using less expensive parts. 

For more details, see ros.org/wiki/TurtleCore

December 5, 2012

During his internship at Willow Garage, Jonathan Mace from Brown University worked on building an industrial strength successor to rosbridge, a popular ROS package for connecting to ROS from a Web browser.  His internship concluded with the release of the rosbridge suite, a robust and extensible collection of packages that facilitate Web-based and non-ROS connection to ROS.

Web browsers are a compelling choice for writing front ends to robot applications.  In particular, they offer a ubiquitous, interoperable platform for robot interaction.  Given that end users of robot applications may require little or no knowledge of the underlying robot middleware, decoupling a Web-based front end from a ROS-dependent back end is a promising direction to pursue.

In order to facilitate this decoupling, the rosbridge suite provides an access point for Web browsers (and other WebSocket-compatible systems) to access ROS.  The rosbridge suite also provides components to automate install and runtime linking of Web components.  As such, the rosbridge suite makes it much easier for ROS developers to include a Web component to their work.

The rosbridge suite primarily contains a Web server which runs inside the ROS environment.  This Web server listens for incoming WebSocket connections, and exchanges JSON-based messages with connected clients.  Clients can instruct rosbridge to call ROS services, subscribe and publish to ROS topics, or introspect the ROS runtime.  Response messages originating in the ROS runtime are propagated back to the client.  Thus, Web browsers and middleware separate from ROS can still fully interact with a running ROS system.

The structure of the JSON messages exchanged between clients and the rosbridge server are defined in the rosbridge protocol.  In order to make the protocol more extensible and pluggable, it was redefined and formally specified.  It is similar in spirit to the protocol used by the original rosbridge, but offers more customization.

Other packages in the rosbridge suite include: roswww, an HTTP Web server that runs in the ROS runtime; rosapi, a node that advertises services that introspect the ROS runtime; and tf smart throttle, a node that intelligently throttles tf messages for low-bandwidth connections.

The rosbridge suite has been released as a ROS stack and is available here.  In addition, tutorials, client implementations, and more information is available at www.rosbridge.org.