Sunday, September 21, 2014 A Quick How-To

Below are 5 steps to getting the most out of ROS Answers, and hopefully giving the most back to the community in the process:

1. Don't be afraid to ask a question

The name of the site may be "ROS Answers", but there is no point in having answers if there are not questions. Often I find that people comment on old questions, or post answers to old questions, hoping to get help for a possibly related problem. Your comments will probably be missed by anyone who did not previously participate in that question/answer thread, and posting an answer with a question is just bad etiquette. If you have a question, open a new question!

2. But before you ask a question, check to see if someone has already asked and answered the exact same thing!

There are over 15,000 18000* questions on ROS Answers. There is a good chance that if you have a common problem, it has already been asked, and probably answered. The average time between posting a question and getting answer is probably several hours, however, if you spend just a few minutes searching the site you might find your answer immediately.

3. If you ask a question -- try to make sure other people will be able to find it some day by adding appropriate tags.

That search thingy in #2 depends on questions being properly tagged. Adding a few (useful) tags will both help get you an answer faster, as well as making sure that the next person with the same question can find your question and the answer to it. "ros" is probably not a useful tag, the name of the package, node, or command in question would be good tags. Including tags for the specific hardware you might be using could also be useful (for instance "kinect" or "pr2")

4. Close button is evil. Karma is good.

This is probably the most misunderstood aspect of ROS Answers. People frequently post a comment saying "thanks, that works" and then click the "close" button on the question instead of selecting an answer. Please don't do this! Instead, click the checkmark next to the question to select the answer to your question. You can only select the answer on questions that you asked, however, if you find an answer to someone else's question that helps you, you can give a little Karma by clicking the "up arrow". The answer to the right here has been upvoted 26 times -- it must be pretty good.

The answers website really depends on Karma. New users have restrictions (unable to post links, images, etc).  New users NEED Karma to become more effective users. Power users need Karma to be able to moderate the site, like retagging those questions where people didn't get the tags right.

5. Finally, make sure somebody can actually maybe answer your question.

Good answers require good questions. If you get an error in the console, certainly include that exact error into the question. A summary of the error, or "I got an error" are not substitutes for the actual error or traceback. Tells us exactly what commands you ran. Other things you probably want to include: what ROS version, operating system, and robot you are running -- and if you aren't running from up-to-date debs from the OSRF apt repo, you probably want to point out how you installed ROS.

* I started writing this post a few days after the 15000th question was posted. I finished writing it 3000 questions later....

Saturday, September 6, 2014

Intel NUC for ROS

This post has been a long time coming -- I think I promised it to several HBRC members at the July SIG...

I've frequently been asked "what computer do you use on your robots?", usually from someone looking at a variety of sub-$100 ARM boards. ARM processors have come a long way, but for a ROS computer, they are not the easiest choice. Austin Hendrix has done a lot of work to get a buildfarm up and running for ARM processors -- but there is still a long way to go and many things will not work "out-of-the-box".
So my choice? Well, it's not under $100, but it is a very fast, fairly low power machine (here, I define low-power in the sub-15W range). The latest generation of Intel NUC (Next Unit of Computing) modules offer quite a few options for small Intel Core-based computers. I'm using the 4th-generation i3-based D34010WYK. This offers quite a bit of compute power for ROS, especially when you consider that early TurtleBots ran on a single-core Atom. I've used 35W TDP i3 processors on a number of mobile manipulation problems and been able to run the OpenNI/OpenNI2-based drivers, the navigation stack and MoveIt! without much difficulty. If you're looking for a bit more processor, there is an i5-based version for $100 more.
Intel NUC (image from Intel NUC website)
These computers are sold as either a board (somewhat hard to find for sale) or as a kit which includes the case. Either option requires memory, hard drive and wifi card to be added. My setup is:
  • 8GB Crucial Ballistix Sport SODIMM. Whatever you choose, be sure it is 1.35V RAM -- the newer NUC models work ONLY with 1.35V RAM (many modules are 1.5V).
  • 120GB Crucial mSATA SSD. Intel offers a larger case version of the NUC that fits a standard 2.5" drive, but the smaller versions only take an mSATA drive.
  • Intel 7260 Wireless-AC Card. This card will work best with Ubuntu 14.04, older versions will need an updated kernel (at least 3.13) to get working drivers. No need for antennas as they are already in the case.
These boards take 12-24V DC input, but are probably most efficient at 19V. I'm powering mine off a 12V battery connected to a Pololu 5A Step-Up Regulator that is configured to output the desired 19V. My batteries will never get even close to 19V even when fully charged, and so the regulator should not have any issues.
I would recommend installing Ubuntu 14.04 and using ROS Indigo for these machines. If you want to use an older Ubuntu distro, you should definitely make sure your wifi card is compatible, because the Ethernet port will not work with the drivers present on the 12.04 installer and you will have to connect to to update somehow. Another alternative is to look for a NUC based on the 3rd-generation Intel Core processors, but these might be hard to locate.

Sunday, February 23, 2014

It's actually alive!

Over a year ago, I posted about my RoboMagellan robot, and then nothing. It's been pretty busy for the past year, but I finally got back to working on this robot. The control board is now mostly functional, and I have integrated the IMU and GPS. I still have to get the tilting laser assembly mounted and working, and come up with a permanent mount for the camera, but earlier today I finally field tested the robot:

Drives well in grass, on pavement, and even has enough gusto to get up onto concrete parking lot wheel stops (although it tends to then get stuck on top of said stop). The forward odometry is good, but I still need to tune the turning odometry.

As far as ROS integration goes, I have the IMU, GPS, and wheels tied into ROS. For decoding the GPS I'm using the nmea_navsat_driver package, which made things quite easy. I'm currently working on some tools for handling localization and visualization while in a GPS coordinate frame (more to come on that, but it is developed on top of geodesy). Code for the project is pretty minimal right now, but is hosted at

Sunday, September 29, 2013


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:

Tuesday, May 21, 2013

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

Tuesday, April 30, 2013

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:

Monday, April 29, 2013


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