I’m in charge of the vision system for Project Centaur. The vision system is responsible for identifying locations on pipes for the robot arm to approach and measure. To accomplish this, we are using an Xtion PRO LIVE, which is a 3D sensor similar to the Kinect. To vastly broaden our possible field of view, we decided to mount the Xtion on a pan-tilt mechanism.

The pan-tilt mechanism that we’re using is made by Robotis, and uses two Dynamixel AX-12+ motors for panning and tilting. An image of it can be seen below. My job was to get it panning and tilting via ROS commands.

To start, I just wanted to get some sort of programmatic control working without using ROS. I found and downloaded the SDK, which is useful in that it provides bindings for many different programming languages. The only practical options here were C++ and Python, since those are what ROS (easily) supports. I chose Python because it’s much faster for prototyping and I just like it a lot better than C++.

I opened up one of the Python examples provided with the SDK. It was quite informative, but it showed that thin bindings to C functions were all the SDK provided. As such, I set out to create a much nicer Python object-oriented interface for the motor. Using my interface, one could easily initialize, shutdown, set speeds, and read and write the pan-tilt values, instead of having to directly write bytes to specific addresses on the motor controller.

With a nice interface complete, the last step was to build a ROS node on top of it. I created a simple node that publishes the pan and tilt angles, in radians, and subscribes to a Twist message for movement. This will allow us to easily integrate the pan-tilt mechanism into the overall system.

The code which I’ve written for the pan-tilt is not currently open-source, but I may post it after further testing.

Our project is using the ST Robotics R12 in order to perform thickness measurements on pipes. We plan to do this by positioning an ultrasonic sensor against those pipes, allowing thickness measurements to be read. In order to perform that sort of action, we need to have good control over the arm. And in order to test our control, we want to have a simulated model of the arm.

Since we plan on using ROS to run our project, we have several good options to do this. First of all, we have Gazebo and rviz as simulation and visualization/debugging tools. Second, the MoveIt! software package will allow us to develop motion plans for the arm.

I was able to use CAD files to create a URDF model of the R12 arm. I put this into a new package, created a Gazebo world for the arm, and created a package with ros-control plugins. With all of this done, the arm could be spawned in Gazebo and controlled over ros-control topics. The arm can also be visualised in rviz, allowing the visualisation of motion plans and other data alongside the arm.

 

 

 

 

 

 

 

 

After this, I developed a MoveIt! package to control the R12. Luckily, MoveIt!’s setup assistant was able to work through most of the details of creating the original package. Once that was made, there were some problems in actually using MoveIt! to solve a motion plan. I found out after some work that this was due to the arm being a 5-DOFarm, which MoveIt!’s planning library does not support well. I was able to tweak some settings after this to get reasonable performance.

With this done, I was able to perform my first round of tests for further development. In order to reach around the pipe to gather the best data, we needed to design an end-effector to help reach around the pipe. I came up with some different conceptual designs, and created simulated models. MoveIt! was able to adapt easily to switches between them. With each of the models, I tested MoveIt!’s ability to create a motion plan to various points around a pipe, while avoiding collisions with that pipe.

Contrary to what I had expected, one of the best designs was a near-direct attachment of the probe on the end of the arm. This looks like a nice simple design that we will be implementing in the future.

 

 

 

 

 

 

With this done, the next task will be integrating direct joint information from the R12 to ROS, as well as translating MoveIt!’s motion plans to a form that the real R12 can use and execute.

The robot arm being used in our project is the ST Robotics R12. The purpose of the arm is to position an ultrasonic sensor against pipes to measure their thickness, thus checking for deterioration. The only software interface provided with the arm was a proprietary Windows client, which allows one to connect to the arm, send commands, and read the responses. However, this software did not cover our needs. The first problem was that we wanted to use ROS for the project, but ROS only runs on Linux. Second, the Windows interface did not provide an easy way to programmatically control the arm. As such, we needed to create our own solution.

Luckily, the Windows client does not do any command processing. The arm is controlled using Roboforth commands, which is a proprietary language developed by ST based on Forth. The Roboforth commands are sent as-is and processed by a microcontroller on the arm itself. The microcontroller sends the resulting signals to a separate digital signal processor which in turn drives the motors. Not having to do any command processing on the client-side, made our job quite easy. I was able to write a simple Python script to open a serial connection with the arm and provide an API to read and write to it. I also created a command-line shell program to control the arm interactively, and bundled it all into a Python package.

The Python package is now being used as a back-end for the ROS node we are developing for the arm. The code for the package is open-source, so I hope that others working with the R12 find it instructive and useful.