This script is still included in the repo, but will not be improved in the future.

The purpose of the YuMi MoveIt! interface script is to interface YuMi with the MoveIt! library and RAPID Module translator functions through a set of command line inputs. YuMi can then be manipulated on a strictly simulated environment or on an existing YuMi.

• Before Running the Script
• Starting the Script
• How to Use the Script
• ABB YuMi RAPID Module Conventions Used

Before running the script, YuMi needs to have been loaded into to ROS. To information on how to load YuMi into ROS, please look below. Once YuMi has been loaded, then the script can be run (instructions for running the script are in the next section).

If you will be using an existing YuMi, please run the the commands below in separate terminal windows to load YuMi into ROS. Please ensure that after executing the first command that the state/motion servers have loaded properly before running the second command. For more information on how to know if the state/motion servers have loaded properly, please take a look at the Setting up ROS wiki page.

yumi_server state_servers_only two_grippers
yumi rviz two_grippers

If you are not using two grippers, then replace two_grippers with the appropriate command for both lines. For more information on appropriate commands, please refer to the YuMi Quick Commands page.

If you will be using only a simulated YuMi, please run the following command:

yumi_demo rviz two_grippers

If you are not using two grippers, then replace two_grippers with the appropriate command. For more information on appropriate commands, please refer to the YuMi Quick Commands page.

Back to top

To start the YuMi/MoveIt! interface script, run the following command:

yumi_moveit

yumi_moveit is a YuMi quick command, for more information on how to use the command, please refer to the YuMi Quick Commands page.

When the above command is executed, the program will create the relevant move groups and IK solvers for the armsof YuMi, and then will wait for commands from the user as described in the section below. The command above does not require/have any additional/optional parameters.

Back to top

Once the program has been started and the terminal window has cleared with the line below displayed at the top of the window, then the program is ready to accept arguments from the user.

[ INFO] [#]: Ready to take arguments. For a list of recognized arguments, enter "help"

This program will wait for an argument from the user, determine if the provided argument is one of the recognized arguments, and if so will perform the appropriate operation as described below. Otherwise the user will be notified that the argument was not one of the recognized arguments and will wait for another input from the user. The arguments must be typed into the terminal window, and clicking the enter button on the keyboard will run the argument through the argument list.

Note: Normal terminal commands do not work in this program other than clear. Previous commands can not be retrieved by pushing the up arrow on the keyboard and so forth.

If the user would like to load a module called test_module_left.mod for the left arm and execute the trajectory, then the following commands should be executed:

module left test_module_left
run left

If the user would like to load modules with the names of test_module_left.mod and test_module_right.mod for the left and right arm respectively, run these modules through the planner without executing, and save the planner data structure as test_module.bag, then the following commands should be executed:

module both test_module_left test_module_right
run both dont_execute
rosbag save test_module

If an error occurs while the planner data structure is being created, then the last command rosbag save test_module will not be allowed to be executed since only planner data structures that have been constructed properly can be saved.

Please note for the additional arguments below that the $ symbol indicates that the shown variable name should be replaced by a name (ex: file name), and the <> symbols indicate that the user should choose one of the options listed within the angle brackets.

Setting Module Names

There are two sets of additional arguments that need to be passed along with module from the terminal window. The first set of commands specifies which arm the supplied RAPID module name is meant for. The second set of commands specifies that RAPID module names for both arms will be supplied, first the left arm RAPID module name then the right arm RAPID module name.

The RAPID module name should not include file extensions (ex: .mod) and they should be located in the modules folder from the yumi_scripts package in the YuMi workspace. When the run command is executed, the program will search for the RAPID module supplied for the arm(s) and translate them into a data structure that will be run through the planning and execution pipeline. After the command is run, the module(s) will be checked to ensure that they exist otherwise an error will occur and the module name will not be stored.

module <left/right> $module_name
module both $left_module_name $right_module_name

Running or Saving Planning Data Structure from/to ROS bags

There is one set of additional arguments that need to be passed along with rosbag from the terminal window. The first argument indicates if the user would like to run a rosbag file that has been saved previously from the YuMi MoveIt! interface script, or save the planning data structure that has recently been generated from the planning and execution pipeline.

The rosbag file name should not include file extensions (ex: .bag) and it should be located in the bags folder from the yumi_scripts package in the YuMi workspace. A planning data structure cannot be saved unless the last execution of the run command was successful with no errors. To check if the last run was successful, run the state command and a line will be displayed saying, "Planner ready to be saved: <yes/no>" indicating the previous planning structure is ready to be saved.

rosbag <run/save> $file_name

Changing the End Effector for the Inverse Kinematics Solver

There are two sets of additional arguments that need to be passed along with end_effector from the terminal window. The first set of commands specifies the arm that the provided end effector should be applied to for the IK solver. The second set of commands specifies the end effector to be used for each arm for the IK solver.

If the provided end effector is not spelled correctly or cannot be an end effector, then the user will be notified with an error and the program will wait for the next command by the user.

According to the current layout of the SRDF's, the list of possible end effectors either arm is shown in the list below.

According to: 2016-08-10

List of possible end effectors: (for the right arm, replace "l" with "r")

• yumi_link_1_l
• yumi_link_2_l
• yumi_link_3_l
• yumi_link_4_l
• yumi_link_5_l
• yumi_link_6_l
• yumi_link_7_l
• gripper_l_tcp (only for arms with a gripper attached)

end_effector <left/right> $end_effector_name
end_effector both $left_end_effector_name $right_end_effector_name

Run Through the Planner and Execution Pipeline

There is one set of additional arguments that need to be passed along with run from the terminal window. The first argument indicates which arm and associated RAPID module should be run through the planning and execution pipeline. The second argument, dont_execute, is optional which can be supplied if the user would only line to run it through the planner and not to execute the generated plan.

If there are any issues during the planning and execution pipeline, and error will be supplied to the user and the pipeline will be exited. If the program is set to run debug mode, most of the issues that could occur will be skipped and the script will attempt to still form a planner data structure even with error. When running in debug mode, the result may have an unexpected behaviour.

run <left/right/both> (opt: dont_execute)

Changing Whether Program is Run in Debug Mode

There is one additional argument that need to be passed along with debug from the terminal window. This argument can be on or off indicating if debug mode should be set to on or off when the planning and execution pipeline is triggered. If debug mode is off, then only high level feedback will be provided to the user in respect to the current operations being performed by the script. If debug mode is set to on, then the user will be notified of the current calculations, conversions, and the location of the program pointer being performed.

debug <on/off>

Removing or Forcing Bounds on the Inverse Kinematics Solver Based on Axis Configuration Data

There is one additional argument that need to be passed along with bounds from the terminal window. This argument can be on or off indicating if the axis configuration data should be used to force bounded solutions from the inverse kinematic solver. Since YuMi has 7 DOF, there is generally a large amount of redundancy for a given pose, and thus the axis configurations stored in each robtarget (described below in the section ABB YuMi RAPID Module Conventions Used) will allow for the IK solutions to be consistent due the solution being bounded.

bounds <on/off>

Back to top

ABB YuMi axis naming convention (from YuMi base to end effector): [1, 2, 7, 3, 4, 5, 6]

ABB axis configuration convention: [axis_1_config, axis_4_config, axis_6_config, cfx]

ABB axis configuration values for axis_1_config, axis_4_config, and axis_6_config:

• The configuration values above are for joints 1, 4, and 6

Description for cfx: if cfx = ABCD

• A represents configuration for axis 5 and can be either (1) or (0)
  • (0) if axis 5 position >= 0 degrees, (1) if axis 5 position < 0 degrees
• B represents configuration for axis 3 and can be either (1) or (0)
  • (0) if axis 3 position >= -90 degrees, (1) if axis 3 position < -90 degrees
• C represents configuration for axis 2 and can be either (1) or (0)
  • (0) if axis 2 position >= 0 degrees, (1) if axis 2 position < 0 degrees
• D represents the compatibility bit, particularly used for linear movements
  • This value is not used and is always set to (0)

Examples (compatibility bit assumed to be 0):

• Axis 5 = 0 degrees, Axis 3 = -90 degrees, Axis 2 = 0 degrees | cfx = 0000 or 0
• Axis 5 = 0 degrees, Axis 3 = -91 degrees, Axis 2 = 0 degrees | cfx = 0100 or 100
• Axis 5 = -90 degrees, Axis 3 = 0 degrees, Axis 2 = -90 degrees | cfx = 1010

External axis configuration: [arm_angle, 9E+09, 9E+09, 9E+09, 9E+09, 9E+09]

Layout of simple module:

1. MODULE module_name
2. LOCAL CONST string YuMi_App_Program_Version:="1.0.1";
3. LOCAL VAR robtarget s1 := position],[orientation],[configuration_data],[external_axis;
4. LOCAL VAR robtarget p1 := position],[orientation],[configuration_data],[external_axis;
5. PROC main()
6. MoveSync s1;
7. Move p1;
8. OpenHand;
9. CloseHand;
10. ENDPROC
11. ENDMODULE

Module Convention Description:

• First line is always the module name
• Second line always defines that this file is to be used by the YuMi App Program
• Next set of lines define the robtargets in descending numerical order
• Line after the robtarget definitions is the start of the main function
• Next set of lines define the robot arm and gripper movements for the robot to move through
  • MoveSync indicates a synchronized movement with the other arm
    • All variables for these types of movement begin with "s"
  • Move indicates an independent movement from the other arm
    • All variables for these types of movement begin with "p"
• The last two lines indicate the end of the main function and end of the module

Gripper Commands:

• The gripper can either be set to open or close. When set to close, the gripper will close its hand until it is either completely closed, or had grasped an object. The gripper close force can also be set from the TouchPendant (as described in the Moving the Gripper(s) Using the TeachPendant section above).

ABB units: milimeters and degrees

ROS units: meters and radians

ABB robtarget convention:

robtarget_name := [[position.x,position.y,position.z],[orientation.w,orientation.x,orientation.y,orientation.z],[cf1,cf4,cf6,cfx],[eax1,eax2,eax3,eax4,eax5,eax6]]

• cf1 represents the configuration data for axis 1
• cf4 represents the configuration data for axis 4
• cf6 represents the configuration data for axis 6
• cfx represents the configuration data for a combination of axis 5, 3, 2, and a compatibility bit
• eax1 represents the arm angle
• eax2 to eax6 represents 5 other external axis values, but these are not used on YuMi and thus are all set to 9E+09. This data is ignored.

Back to top