Buildbot-ROS

It has been a while since posting, I figured I'd give an update on a project I've been working on recently: a ROS buildfarm using BuildBot.

Of course you are probably thinking, "but ROS already has a buildfarm?" And that is correct, however I found that it was quite hard to setup a personal instance of the Jenkins-based farm that builds ROS Debian packages. There is not all that much documentation, and extending it is not ideal for me as it uses an interesting mix of java-ish stuff.

Enter buildbot. Buildbot is like Jenkins, except completely written in Python, and I like Python. While buildbot doesn't have as many features and plugins as Jenkins, it has more than enough to get the job done. Anyways, I created a buildfarm  using buildbot + catkin, which can do the following:

• Build Debians, just like on the ROS buildfarm. This includes doing it all in a cowbuilder so you know that the dependencies are right.
• Build test jobs, similarly to the ROS buildfarm, whenever you push to a repository (only git is supported)
• Build doc jobs, pretty much like the ROS buildfarm.
• Build arbitrary source debs into binaries.

The system loads its configuration from a rosdistro file. In addition to loading what to build, I also have it setup to load where to get debs from in the rosdistro, making it easy to change deployment setup.

Buildbot-ROS is still quite early in development, but does most of the things that an individual or small team would need internally. The documentation is in the README, which gets nicely rendered by github. The code can be found on my github account: https://github.com/mikeferguson/buildbot-ros

Generating an IKFast Plugin for MoveIt

Over the past few weeks I've been using MoveIt quite a bit -- I was actually using the Pick and Place actions for Maxwell's chess playing last weekend at Maker Faire (an updated on that shortly).

I recently changed over to using IKFast for IK under MoveIt. This fixes a number of problems with the default IK plugin. I'm using ROS Groovy under Ubuntu Precise, and ran into several issues which I thought I would mention here.

First off, I start with the excellent moveit_ikfast_generator from Dave Coleman. You should run his instructions for "Create Collada File for Use with OpenRave". Once you have a collada file, here is what I did to make the ikfast generator work:

      sudo apt-add-repository ppa:openrave/release
      sudo apt-get update
      sudo apt-get install openrave0.8-dp-ikfast

At this point, I had to edit a /usr/lib/python2.7/dist-packages/openravepy/__init__.py to add the following line just after the copyright:

      __openravepy_version__ = "0.8"

Without this, nothing seems to run. Once the code is updated, the tools listed in section 5 of the ROS Industrial tutorial work as indicated.

Then it's back to the README in moveit_ikfast_generator, where the instructions will walk you through generating the ikfast plugin. One note there is also a command for:

    openrave-robot.py my_robot.dae --info joints

which is very helpful if you have a 7-dof actuator and need to fill in the --freeindex parameter.

I'd like to take one quick moment to thank Dave and the ROS Industrial team for their documentation, and Ioan Sucan and the rest of the MoveIt team for the great platform they've provided.

Blast from the Past: PR-MINI

I was recently updating my personal website when I realized that I had some projects that had never seen the light of day. This post is about one of these old projects that I never showed off:

Back in late summer of 2010 I started to build a miniature PR2. It was a 60% scale model of the PR2 arms, base, and torso. The base was differential drive instead of the more expensive casters found in the PR2. I reused the motors and 6" wheels that had previously been used in REX, one of my first large robots. For this robot, the frame was primarily 8020 Aluminum rail covered/connected with laser-cut ABS and the occasional sheet metal bracket:

The head sported a pan/tilt, which used two AX-12s for tilting and a third for pan. It had two webcams for stereo, and was designed with enough space between the web cams to install a Videre short-range stereo camera, although I never got around to that:

The arms were pretty massive, nearly 0.6 meters long, with 7 servos. The shoulder pan, forearm roll, wrist pitch and wrist roll joints were AX-12s. The shoulder lift joint was an RX-64, while the elbow and upper arm roll joints were powered by (admittedly, under-powered) RX-24F servos:

The torso had a 12" throw linear actuator, and used expensive and heavy 8020 parts to form the bearings and rail:

The entire thing was controlled by a laptop, tucked into the base, and an ArbotiX prototype with integrated motor drivers. When dealing with robots this big and heavy, an E-stop is a must. The wiring on the back panel was made somewhat tidy, and covered with Lexan shells:

I went as far as moving arms around under ROS, and tuning in the navigation stack a bit. The code developed for this robot later became the arbotix_ros drivers:

A couple of things did this robot in. First off, it was really heavy (45lbs) and hard to easily transport around (which I was doing a lot of back then). Transport was quite funny as well, because the arms loved to dangle in every possible direction, leading to the "bubble-wrap straight jacket":

Second, the Kinect came out shortly afterwards, making the sensor suite pretty lacking, and looked ludicrous trying to strap a Kinect on this robot. A number of lessons learned are pretty clear in Maxwell, which was built shortly after this robot sacrificed his arms. Oh, and since I couldn't find a reason to slip this picture into the story above, here is a view of the Autodesk Inventor CAD model:

PR-Shelf

PR-Shelf, the most awesome, not-actually ROS-powered, robot shelf:

National Robotics Week: Robot Block Party Pictures

I wasn't at the Robot Block Party last year, but I was amazed this year at how much bigger it was. Two years ago, there were like all of 5 tables on the outside patio, this year there were like 20, and they were all full of robots. I didn't take any photos, but there is plenty of coverage elsewhere: HBRC member Tim Craig took a bunch of pictures. Camp Peavy, another HBRCer took some more pictures.

Updated 4/15: IEEE Spectrum also now has some coverage.

National Robotics Week (and a quick note on MakerFaire)

It's National Robotics Week! And apparently, there is just TOO MUCH ROBOTICS for just one standard week, because NRW spans 9 days, and the website lists events pretty much all month.

There are a number of events in the Bay Area. First up is the Robot Block Party at Stanford from 1-6PM on Wednesday -- there are usually a ton of bots around in a somewhat impromptu show and tell. While I don't think I'll be pulling Maxwell out for this event, I'll probably be there for the later part of the event. Oh, and it's FREE.

Also this week is an interesting event by on Thursday at SRI, put on by Xconomy: Robots Remake the Workplace. Including a keynotes speech from Rodney Brooks.

April 19-21, it's RoboGames! Maxwell will be making an appearance there for sure, likely in the Silicon Valley HomeBrew Robotics Club booth.

And finally, Maxwell will battle PR-Lite at MakerFaire 2013. In chess, that is. That's right, I've dusted off the old AAAI Chess code and the PR-Lite guys have been working to adapt it to their robot. I actually ran into some major issues upgrading the chess code to Groovy as many of the PCL nodelets were not ported forward during the catkinization. So, I took this as an opportunity to rewrite the whole board/piece detection pipeline into a single node that is way faster than the old one, taking into account a number of better heuristics.

I'm still working to integrate MoveIt instead of arm_navigation, but the current code is posted now on github.

Kickstarter Project using an ArbotiX

I just noticed that Kickstarter has a new project posted that is a 3D printed humanoid, which uses an ArbotiX robocontroller:

Very cool! I think this is a first for the ArbotiX. More details on the Kickstarter page.

Catkin Resources and Common Pitfalls

ROS has recently introduced a new buildsystem, called catkin, which is a replacement for rosbuild. One of the greatest strengths of this new buildsystem is that it is pure CMake, which makes it highly portable, standard, and awesome. However, one of the biggest weakenesses of this new buildsystem is... well, it's entirely CMake, so it is a steep learning curve at times, and easily ridden with bugs.

In typical ROS fashion, there are a number of tutorials on catkin (http://ros.org/wiki/catkin/Tutorials). However, there really is a ton of info that is hard to compress into a small set of tutorials.

The rising tide

You'll often hear the term "wet" and "dry" for catkin versus rosbuild. The important take away here is that it is indeed a rising water level. In other words, "wet" (catkin) packages cannot depend on "dry" stuff. This means you have to wait (or jump in and help) on any rosbuild package that you depend on. The quickest way to see what is catkinized is to look at http://ros.org/debbuild/groovy.html. If it says wet, all good. If something is listed as dry there, it may still be catkinized in preparation for hydro, but only the dry version went into groovy, so check the source repo for a hydro-devel branch or similar.

How is the workflow different?

Catkin moves ROS towards a more standard Filesystem Hierarchy System (FHS) as detailed in REP 122 as well as introducing out-of-source builds and install targets. Understanding this FHS is key to proper catkin package design, especially the install step.

How is a catkin package different from a rosmake one?

In rosmake, we had packages and stacks. In catkin, there are only packages. New catkin packages have a package.xml instead of a manifest.xml and there are a number of changes to the set of available tags. Especially different is that dependencies are all now of one time (no longer are packages/stacks/rosdeps treated differently), but also you specify whether dependencies are needed at build or run time. So what about stacks? Well, they were really nothing more than a nice way to group a series of packages together. In catkin, this is handled by a metapackage. A metapackage has only a package.xml, with rundepends tags for each package in the old stack. Details of catkin's pacakge.xml can be found on http://ros.org/wiki/catkin/package.xml.

In addition to package.xml, CMakeLists.txt still exists, but is basically completely different looking. If you are using Python for anything other than rosrunned-scripts, then you will almost need to create a setup.py. There is a migration guide available on the wiki.

Long Live Roslib. Roslib is dead.

One of the major changes now is that with the new FHS, catkin-based Python scripts no longer need to do a "import roslib; roslib.load_manifest()" as the Python path already includes all your installed catkin-based packages. This also means it's easier to test stuff by starting a Python shell and importing just about anything. Just be sure to include the appropriate setup.bash file to get the paths right.

One potential pitfall of this is that if you used to just throw all your python source into "package_name/src", you'll want to start doing "package_name/src/package_name" instead (and be sure to have an __init__.py file in there). This makes the setup.py script dead simple, and also ensures you get a real "python package" with the same name as your "catkin package".

Further Reading

As with any new system, there are a number of questions that arise which maybe the docs don't fully cover. Here are a couple really good ones from ROS Answers over the last few days:

• http://answers.ros.org/question/58498/what-is-the-purpose-of-catkin_depends/
• http://answers.ros.org/question/57968/where-is-catkin_add_nosetests-documented/
• http://answers.ros.org/question/59163/how-do-i-install-a-python-module-with-a-different-name-than-the-catkin-package/
• http://answers.ros.org/question/59648/catkin-metapackage-now-requires-cmakeliststxt/
• http://answers.ros.org/question/60994/pkg_name_generate_messages_cpp-vs-pkg_name_gencpp/
• http://answers.ros.org/question/61027/catkin_make-fails/
• http://answers.ros.org/question/80936/why-are-there-entries-in-rosdistro-for-ros-independent-libraries/
• http://answers.ros.org/question/84616/help-understanding-system-and-package-dependencies-with-rosbuild-and-catkin/

I plan to keep adding to this list...

Update: ROS on Arduino

It's been about 18 months since ROSserial was first released. Since then, ROS has undergone a number of changes, including a new build system, new message generators, and more. Unfortunately, this massively broke ROSserial.

Over the past few weeks, I've spent a bit of time fixing up ROSserial to use the new ROS build system, catkin. I've updated things so that message generation *mostly* works. I'm sure there are still a number of bugs in there, but it's now mostly working again and has just been released into Groovy as version 0.4.3 (currently on shadow-fixed, should be in the public ROS debian repos in a few days).

Recently, ROSserial has been moved to github like so much of ROS. Across the board, the move to github appears to have greatly increased community participation. Speaking of the ROS community, there is another ROS on Arduino package recently released: ros_arduino_bridge. Patrick Goebel of PiRobot.org and the Homebrew Robotics Club recently released this package which is primarily aimed at controlling a differential drive base. I've frequently heard people ask about running a diff-drive base using ROSserial, but the biggest problem is support for the massive nav_msgs/odometry message. This new package doesn't have the flexibility of ros_arduino_bridge, but definitely gets the job done for a mobile base.

Finally, ArbotiX drivers have had some minor updates and have been moved to catkin, and are released. Version 0.8.1 should be in the next set of public ROS debians.

-Fergs

Move'n'It

I've recently gotten a chance to play with MoveIt -- a new manipulation framework for ROS. MoveIt is the replacement for arm_navigation in ROS Groovy and later. Like arm_navigation, MoveIt allows you to plan, in collision free space, the movement of your robot arm. However, unlike arm_navigation, it was designed from the ground up as a series of C++ libraries, with thin ROS wrappers, meaning it is far more extensible.

In the past, I had wrapped arm_navigation's move_group with the simple_arm_server package, which allows 5-DOF arms, like Maxwell's to work with MoveIt. This time, I've taken the easy way out and just added a 6th degree of freedom, an upper arm roll:

I had one extra MX-64 around, and printed a couple of brackets on a MakerBot Replicator (files are posted on Thingiverse). With this extra servo, all of MoveIt pretty much works out of the box. Once I wanted to control the real robot, I ran into a bit of issue. While I've heard that you can use the PR2 controller manager plugin, I couldn't quite get the settings correct. I therefore created a simpler version, which you can find in Maxwell's github in the simple_moveit_plugins package. Here's a quick shot of RVIZ with the MoveIt plugin:

While MoveIt is still version 0.3.20 something, it's actually pretty awesome.

3D Mapping is Here

It's just about 2 years since Willow Garage ran the ROS 3D contest to see what the community could come up with for Kinect/OpenNI applications. The full results are here. The winner in the "most useful" category was a 3D SLAM application called RGBDSLAM. I remember trying to get it running, I eventually did, but it was not easy.

Just this past week I saw a post from the guys over at CCNY, showing off their new visual odometry and keyframe (offiline) mapping system. I decided to give it a try... and it worked out of the box no problem. Here's a video CCNY posted:

A few days later I came across a video (and code with ROS wrappers) from IntRoLab at Sherbrooke:

I also have noticed that RGBDSLAM is still getting updates and documentation revisions, so it is still getting active improvements.

I'm thinking it would be really cool to put together an application that turn these 3d maps into 2d maps usable by the ROS navigation stack. Robots like TurtleBot can typically localize against a map with just their Kinect-like sensor, but building maps has traditionally been tough due to the lack of features visible in a 57-degree wide "fake-laserscan".

This is really awesome stuff for the robotics community -- we have at least 3 different 3D mapping applications released into the ROS ecosphere. Are there more out there that anyone knows of? If you've used these apps, feel free to comment!

-Fergs