Robotic Arms

Robotic Arms

This page provides information on how to run and control a robotic arm in USARSim using the ROS interface.

1. To place an arm in a world, you must first run a world on the windows side. For this example, the ImprovedTestRoom.bat file is used. Running this .bat file will launch a USARSim test environment.

2. On the linux side, edit the usarsimKR60.launch file and have it point to your USARSim host.

3. Run the file: $ roslaunch usarsim_inf usarsimKR60.launch

4. It is recommended that you run an instance of the rxconsole in order to see all of the potential error messages. Note that this needs to be started after the roslaunch command.

This may be done with the command:
$ rxconsole &

Setting Up Arm Navigation in ROS/USARSim

1. Install the arm navigation stack with
   $ sudo apt-get install ros-electric-arm-navigation (for ROS electric) or $ sudo apt-get install ros-fuerte-arm-navigation (for ROS fuerte).

2. Create an URDF file to describe the robot (instructions for generating one automatically from USARSim are here.

3. Put the URDF file in the usarsim_inf/urdf directory. This example uses the KR60 arm, so the urdf file is named KR60.xml. Run the planning description configuration wizard with

roslaunch planning_environment planning_description_configuration_wizard.launch urdf_package:=usarsim_inf urdf_path:=urdf/KR60.xml

• When the wizard starts, hit "Next" to use the default settings. Select "Add kinematic chain group," and select KR60Arm_link0 for the base link and KR60Arm_link6 for the tip link. Name the chain KR60Arm, and click "Add Group."

• If there are no more actuators to add (the KR60Arm should be the only actuator on the KR60 robot), select "Done adding groups."

• Generate the wizard's configuration files in the top level ROS usarsim directory. The wizard will create a package named KR60_arm_navigation (Note the distinction between KR60_arm and KR60Arm--KR60 refers to the robot, KR60Arm to the arm actuator). Exit the wizard once the files have been generated.

• Create a launch file for your robot in usarsim_inf/launch. The easiest way to do this is to modify the usarsimKR60.launch file, making sure to fill in the robot's name, type, and URDF file location.

• Launch the robot and its navigation stack with

    roslaunch usarsim_inf usarsimKR60.launch

    roslaunch KR60_arm_navigation KR60_arm_navigation.launch 

• Launch the set_goal node by running $ roslaunch usarsim_set_goal set_goal.launch --screen. If the --screen parameter isn't set, then the goal prompts won't be visible.

• Enter the goal position and orientation for the tip of the arm to start the plan.

See here for more details on what messages are passed between the set_goal node, the arm navigation stack, and the main USARSim ROS node.

Goal Options

By default, the position given in the set_goal node is an offset in global coordinates, and the orientation is an offset in local (actuator tip) coordinates. The set_goal launch file takes three arguments to change this behavior:

• position_frame: Set to local to control the arm position in local (tip) coordinates, or global to control it in world coordinates (default: global)

• orientation_frame: Set to local to control the arm's orientation in the actuator tip frame, or global to control it in the world frame (default: local)

• control_offset: Set to true to specify the arm position as an offset in whichever coordinate frame is being used, or false to specify an absolute position in the position frame. Note that if position_frame is set to local, this argument has no effect. The default value is true.

For example, to control the absolute position and orientation of the arm in world coordinates, run

$ roslaunch usarsim_set_goal set_goal.launch --screen orientation_frame:=

global control_offset:=false 

Potential Problems

If the arm doesn't move to the goal after it's sent, there are several possibilities:

• The IK solver can't find a solution because a solution for that goal pose doesn't exist. One way to check whether this is the case is to run the planning components visualizer with $roslaunch <robot_name>_arm navigation planning_components_visualizer.launch. After hitting 'interact,' you can use the mouse to drag around the target point and see if the solver can reach it.

• A solution exists for the goal point, but for whatever reason the IK solver can't find it (this occasionally happens on more complex arms). One way to fix this is to increase max_solver_iterations and max_search_iterations in the constraint_aware_kinematics.launch file, located in the autogenerated arm navigation package. For the KR60, for example, try adding the following lines to the main node in KR60_arm_navigation/launch/constraint_aware_kinematics.launch:

    <param name="KR60Arm/max_solver_iterations" type="int" value="1000" />
    <param name="KR60Arm/max_search_iterations" type="int" value="10" /> 

• There may be a problem with joint limits in USARSim. USARSim does not always behave correctly with joint limits greater than 180 or less than -180 degrees, and may lock up unexpectedly if those limits are reached. You can avoid most of these problems by making sure the upper joint limit in USARSim is always less than or equal to pi, and the lower limit is greater than or equal to -pi.

• Occasionally, the arm_navigation node fails not because it cannot solve an IK position, but with an error message stating that "Duration is out of 32-bit range." This problem has yet to be resolved, since it is difficult to reproduce reliably.

Current Issues

• The navigation server doesn't recognize preempt requests and will never cancel motion once it's been started. However, due to what seems like a bug in ROS, the navigation server will never receive a preempt request anyway (see http://answers.ros.org/question/39257/interrupting-a-joint-trajectory/ ).

Possible fixes:

• Instead of sending a MoveArmAction preempt request, send a new goal that matches the current arm position (possibly using the joint_states topic to create a joint goal).

• Create a custom version of the [move_arm] (http://www.ros.org/wiki/move_arm) node and add a call to stopTrajectory() around line 1144 of move_arm_simple_action.cpp (when the MoveArmAction goal is explicitly preempted). This has been tested, and it should result in a preempt request being sent to the FollowJointTrajectoryAction server at the correct time.