Wanting to take advantage of the many packages available in the ROS ecosystem, I wanted to get the uArm metal up and running with the uArmForROS library that is available on the uFactory github.

Experimenting around with it revealed it has some nice features - you can visualise the system and steer the end-effector around through RViz, as well as standard things like you might expect such as setting end-effector positions in Cartesian coordinates, or setting joint angles.

While this initially showed promise, the overall experience of using the package was a bit... weird. Getting position data didn't work quite how I thought it should, sending robot commands seemed to have a lot of overhead, and the process for getting the robot up and running seemed a bit roundabout. It got me thinking about some alternative ways to integrate the uArm with ROS.

(For the impatient:

Quick test of the uArm ROS package from Joey Song at uFactory: for main python library

Some key gripes that motivated developing an alternate package::

  1. Accessing robot data via the ROS parameter server.
    • This seems like an odd design choice, over publishing robot data on a topic, given that ROS parameters are meant for static data that doesn't need updating too often.
  2. Sending robot commands by calling ROS nodes.
    • Calling a ROS node every time I wanted the robot to do something seemed a bit unnecessary,
  3. Read/Write conflicts.
    • I found during tests that attempting to read and write to the robot too rapidly would result in a system error requiring reconnection to the robot. This was problematic for my application, so some way of managing the read/write requests was needed.

I'm not saying the uFactory ROS interface is necessarily bad, just that it doesn't offer ROS functionality in a way I was expecting it too. There may well be good design decisions behind their chosen approach, and there's a chance I've missed some key ingredient, but ultimately I felt a package that interacted with the uArm in a way that seemed more ROS-like was needed. I've put together an alternate ROS package which I think addresses these issues. I've chosen implementing a separate package over attempting a pull request, as the approach I've taken represents major changes to the original package.

That said, with the same dependencies as the uFactory package, you can just follow section 1.1 in their read-me to get up and running (using ROS Indigo with Ubuntu 14.04).

/uarm_metal package ROS topics - see more at

/uarm_metal package ROS topics - see more at

One caveat to this package is that it doesn't feature RViz integration (just yet)- it's more designed to allow for better integration with code, and a smoother read/write process.

I'll be giving the details of my approach over the next few posts (they will be more regular, I swear), but if you'd like to try it out you can find the package over at my github