##Baxter and Asus Xtion - Using Point Cloud Data to Manipulate Cylinders From Perceived Mass By: Ritwik Ummalaneni, Athulya Simon, Jackie Wu, Sherif Mostafa, and Austin Lawrence

Please click here to see a video of baxter using this package for intelligent object manipulation.

Table of Contents

Abstract

Introduction

Methodology

PCL

Robotic Kinematics

Results

Discussion

##Abstract The group utilized an Asus Xtion RGBD camera to estimate the volume and transform configuration with respect to a Baxter research robot. From there, Baxter lifts each object, measures gravitational force via a measured wrench applied to the end effector, estimates mass, and spatially sorts based on increasing values. The team primarily faced two issues in collision avoidance, as well as camera calibration.

##Introduction The team's original objective was to evaluate Baxter's reliability in determining weight of a container containing fluid-like material and subsequently pouring its contents among nearby containers. The team split into two main groups: one for handling kinematic control, and the other for point cloud data. The teams met periodically to discuss milestone updates and later synthesized their work during the concluding days of the project timeline.

##Methodology The team collectively agreed transact a custom ROS message from the PCL group to the Manipulation group, which dictated the approach taken by each member. Broken down between two groups, the methodology is as follows:

####PCL Detect a cylinder - The Cylinder Model Segmentation tutorial from the PCL library was used as a primary resource. After finding the first cylinder, the point cloud for that cylinder is removed, and then a second cylinder is found. A similar process is repeated to find the third cylinder.

Find ID, position, radius, and height - The cylinder segmentation returns 7 model coefficients - the first 3 are the x,y,z coordinates of a point on the cylinder axis, the next 3 define the axis direction, and the last number is the radius of the cylinder. Since the cylinder axis is returned as a line with an infinite domain, the height of a cylinder is determined by calculating the distance between maximum and minimum y values. 10 samples are collected to improve consistency in measurements. ID, Position, Radius, and Height of Cylinder are published as a custom message, pcl_cylinder.

####Robotic Kinematics Connect to Baxter - Connecting to Baxter is relatively straightforward. A custom IP to communicate with the robot was originally used, and later transitioned to using the computer's local hostname, to avoid unnecessary changes in IP. The Rethink Robotics tutorial was heavily relied on, which if followed verbatim, seemed to work reliably.

Control an arm with inverse kinematics - Baxter's arms are controlled by passing in arguments through the baxter_interface API. The tutorial utilized is found here. Solutions for arm trajectories can be generated by passing in a desired end effector configuration through the Baxter IK service. All IK service requests must be provided with respect to Baxter's base frame, so data transmitted from a remote camera must first undergo a TF transform.

Control an arm with respect to a foreign (Xtion) frame - Using TF, two transformations were generated early during the project to represent the configuration of the Xtion: 'temp', and 'xtion'. To account for variation in the camera placement, it was necessary to calibrate the Xtion camera with respect to a camera frame on Baxter. Using (ar_track_alvar)[http://wiki.ros.org/ar_track_alvar] to produce transforms from tags, a new transform frame is produced that represents the placement of the Asus, and thus meaningful data for controlling Baxter's arms.

Thats the plan at least. The idea is, we obtain the transforms between an object to the Xtion's frame and to baxter's camera frame. We then update our tree with the transform between the Xtion to baxter's base frame. All the well documented packages i.e ar_sys, visp_auto_tracker, ar_pose do not serve this purpose well as they do not provide tf information. ar_track_alvar is the closest we have come to obtaining a tf between the Xtion and the marker object. We are still figuring out how to obtain the transform between the marker object to baxter. Once we have that, publishing a static transform should be pretty trivial.

##Results Every individual factor within this project are working successfully, though there has been trouble integrating all of the parts together. This stems from a struggle from the following two problems:

1. The transform between the Xtion and the robot's end effector is inaccurate

2. The weight calculation based on Baxter's provided end effector wrench is inconsistent and non representative to the actual mass of the object.

We also cannot get our launch file to work, so please run the files seperately.

##Discussion To solve the aforementioned problems, the team will do the following:

1. Extrinsic automatic calibration with the Xtion to the robot. As we mentioned:

"All the well documented packages i.e ar_sys, visp_auto_tracker, ar_pose do not serve this purpose well as they do not provide tf information. ar_track_alvar is the closest we have come to obtaining a tf between the Xtion and the marker object. We are still figuring out how to obtain the transform between the marker object to baxter. Once we have that, publishing a static transform should be pretty trivial. "

2. Within the scope of this project, it is not possible to accurately determine the weight of an object. It would, however, be worthwhile to derive the end effector force through the published joint torques and comparing to the forces published within Baxter's end effector wrench.