Split of from ros-industrial/abb_experimental#21.

Current suggestion:

Appendix A: Vendor specific naming

ABB

Variant names for ABB manipulators may include a modifier (indicating support for a particular feature, or a physical characteristic of the variant), a payload specification (one or more digits, indicating maximum supported payload in kg) and finally a specification of the reach of the arm (in meters). Examples: IRB 1600 - 10 / 1.2 and IRB 4400L - 10.

All ABB support packages shall be named using the following template:

  abb_irbMODEL_support

Note that this template omits the modifier, payload and reach components included in the actual product name.

Where appropriate, artefacts within ABB support, MoveIt configuration and plugin packages shall be named using the following template (refer to the Naming section for more information):

  irbMODEL[MODIFIER]_PAYLOAD_REACH_[VARIANT]

Where MODEL is a numeric string, MODIFIER is a string (optional), PAYLOAD is a numeric string (max payload in kg), REACH is a numeric string (reach converted to centimetres, avoiding fractional numbers) and VARIANT may be an alphanumeric string (optional).

If a particular model does not have variants based on reach, the REACH component should be omitted from the ROS-Industrial name as well.

Examples: irb1600_10_120 and irb4400l_10_255.

Upon loading MoveIt in Rviz (via demo.launch for instance) in whichever package results in the following error being printed on the console:

[ERROR] [1378148018.640746037]: Skipping XML Document "/home/user/../abb_moveit_plugins/irb_2400_moveit_kinematics_plugin.xml" 
which had no Root Element.  This likely means the XML is malformed or missing.

I've tried comparing the contents of that file with other IKFast plugin XML files, but can't really find any significant differences.

Reporting it anyway.

The abb driver nodes are incorrectly using byte swapping due to catkin library linking. This is related to a this problem: ros-industrial/industrial_core#10.

The first commit in the dx100 porting branch illustrates how to fix this: https://github.com/ros-industrial/motoman/tree/dx100_driver_update

Also, the fanuc CMakeLists.txt should server as the model for these changes: https://github.com/ros-industrial/fanuc/blob/groovy-devel/fanuc_driver/CMakeLists.txt

The CMakeLists.txt of the abb_common and abb_moveit_plugins packages are missing install targets. This makes it impossible to use them in a install space.

Issue #42 is a true bug. It should be back ported to the hydro release.

When loading the meshes provided as part of the abb_irb2400_support package, I get multiple warnings on the console:

[1463395556.713573853] [ WARN] [ros.rviz]: The STL file 'package://abb_irb2400_support/meshes/irb2400/visual/link_1.stl'
is malformed. It starts with the word 'solid', indicating that it's an ASCII STL file, but
it does not contain the word 'endsolid' so it is either a malformed ASCII STL file or it
is actually a binary STL file. Trying to interpret it as a binary STL file instead.

Probably exported using SolidWorks, which tends to do this.

As the warning says, having solid in the header confuses loaders, so it should be removed.

As per subject.

Many manifests list the email address of @shaun-edwards as sedewards@...

As discussed in ros-industrial/ros_industrial_issues#24.

Several of the currently-listed models (2400, 6640, etc.) actually have multiple variants with different arm lengths, payloads, etc. We should update the packages to be more specific about which variant is actually modeled. This will involve renaming of all current affected packages to be variant-specific, so we'll probably need to mark the current versions as deprecated first, to give users time to adapt.

• IRB 2400 : 2 variants, which appear to only differ in payload capacity but may have different CAD models
• IRB 6640 : 7 variants that differ in arm length, payload, joint range, etc.

Overwritten with default file generated by the MoveIt Setup Assistant (in 0529203). moveit_planning_execution.launch now doesn't work correctly.

URDF tool0 definition was updated in 24f5530, but ikFast analytic solver was not updated. IKFast solver now produces results inconsistent with URDF/KDL.

Test case
Compute IK for robot at nominal (all-zeros) position:

rosservice call /compute_ik "{ik_request: {group_name: 'manipulator', robot_state: {joint_state: {name: ['joint_1', 'joint_2', 'joint_3', 'joint_4', 'joint_5', 'joint_6'], position: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]}}, ik_link_name: 'tool0', pose_stamped: {pose: {position: {x: 0.94, y: 0.0, z: 1.455}, orientation: {x: 0.0, y: 0.707106781185, z: 0.0, w: 0.707106781188}}}}}"

• KDL: [0, 0, 0, 0, 0, 0]
• IKFast: [0, 0.15, -0.28, 0.0, 1.70, 0.0]

Other ABB models are not affected, because no IKFast plugin has been created.

The current MoveIt configuration package (irb2400_moveit_config) has all acceleration limits set to 1.0 in joint_limits.yaml. These are probably not the real limits, and should be updated if possible.

I want move the robot in robotstudio with ros-industrial (virtual machine), but I only can move the robot once.
I use irb2400 abb package.

launch: roslaunch irb_2400_moveit_config moveit_planning_execution.launch sim:=false robot_ip:=<robot's ip>

Additional info:
Windows 7 64 bits
RobotStudio 5.61
VirtualBox 4.3.12
ROS distro hydro Desktop-Full Install
ROS-I intalled binary package
abb packages -> https://github.com/ros-industrial/abb.git

Under section 3 Installing Server Code (here):

All files in the abb_common/rapid directory should be copied to the robot controller [..]

The abb_common package was deprecated in Hydro, and removed in Indigo. The instructions work because they explicitly link to the old Groovy files.

The text and link should be updated. The tutorial should probably be updated to give different instructions for the different releases.

Loading irb_6640.xacro using xacrodisplay.launch from urdf_tutorial results in:

Traceback (most recent call last):
  File "/opt/ros/groovy/stacks/xacro/xacro.py", line 35, in <module>
    xacro.main()
  File "/opt/ros/groovy/stacks/xacro/src/xacro.py", line 554, in main
    process_includes(doc, os.path.dirname(sys.argv[1]))
  File "/opt/ros/groovy/stacks/xacro/src/xacro.py", line 208, in process_includes
    raise XacroException("included file [%s] generated an error during XML parsing: %s"%(filename, str(e)))
xacro.XacroException: included file [/home/user/ros/industrial_groovy_catkin/src/abb/abb_common/urdf/irb_6640_macro.xacro] generated an error during XML parsing: mismatched tag: line 158, column 4
Invalid <param> tag: Cannot load command parameter [robot_description]: command [/opt/ros/groovy/stacks/xacro/xacro.py abb_common/urdf/irb_6640.xacro] returned with code [1]. 

When I insert the TPWrite command in the routine ROS_receive_msg_joint_traj_pt (code shown below), from ROS_messages module, I can see the value sent from ROS side. However, message.velocity does not show anything. If I send any velocity value for a particular joint from ROS, how can I access it in RAPID?

UnpackRawBytes raw_message.data, 1, message.sequence_id, \IntX:=DINT;
UnpackRawBytes raw_message.data, 5, message.joints.rax_1, \Float4;
UnpackRawBytes raw_message.data, 9, message.joints.rax_2, \Float4;
UnpackRawBytes raw_message.data, 13, message.joints.rax_3, \Float4;
UnpackRawBytes raw_message.data, 17, message.joints.rax_4, \Float4;
UnpackRawBytes raw_message.data, 21, message.joints.rax_5, \Float4;
UnpackRawBytes raw_message.data, 25, message.joints.rax_6, \Float4;
UnpackRawBytes raw_message.data, 29, message.velocity, \Float4;
TPWrite "value is " + ValToStr(message.joints.rax_1);
UnpackRawBytes raw_message.data, 29+(ROS_MSG_MAX_JOINTS-6)*4, message.velocity, \Float4;
TPWrite "Q4 value is " + ValToStr(message.velocity);  

The irb2400 plugin was generated some time ago. It should be regenerated to take advantage of new changes and updates.

See #36

Suggestion: please bump the minor nr for the Indigo release (so make it 1.2.x), similar to what was done with industrial_core (0.3.x -> 0.4.x).

That would leave room to release additional versions into Hydro, and also make it clear which release a particular version of abb is meant for (ie: 1.1.x -> Hydro, 1.2.x -> Indigo).

The current versions of the state_interface and the motion_interface nodes don't allow the user to override the TCP port to which they should connect. The default ports (11000 and 11002) are always used (here and here).

This makes it impossible to use the nodes when multiple server instances are run on the same IP (fi on controllers with multiple motion groups).

See detailed write-up on google code here.

Hi!

I'm starting to do work with an ABB IRB 120 and wondering if there was support for this via moveit_configs or URDF/XACRO files to jump off from.

Thanks!

The IRB 14000 has been around for quite some time, so we should add a support package for it to this repository.

I've already seen quite a nr of urdfs 'out there', so importing one of those is an option.

They would have to be adapted to follow ROS-Industrial conventions.

update in groovy changed the function signatures of the kinematics_base.h file. As a result, the irb_2400_manipulator_ikfast_moveit_plugin.cpp fails to build since it can't find any implementation of the base class' virtual methods. Will create a branch for this issue

In this page: http://wiki.ros.org/abb/Tutorials/RunServer , it said that ROS may try to cancel the move, when it takes longer than expected. When I use ROS-I controlling an ABB robot, this situation often occurs. How to disable this behavior?

@shaun-edwards I have download the abb packages and i also can run the nodes 。But i can‘t control the abb totally。For example ，how can i control the abb to walk along with the circular path？

BEST WISH!

As per subject.

This causes the ros-hydro-abb-irb2400-moveit-plugins package not to be included when installing ros-hydro-abb-irb2400-moveit-config, resulting in errors when trying to use the MoveIt Config (as the ikfast plugin cannot be found).

This is a bit silly. But what naming convention should we use for packages of different robot variants (i.e. IRB-1600-1.2, IRB-1600-1.65 and so on)?

According to the ROS naming convention, dots are not allowed, so my question goes for the dot in those variants specifications.

Should we use an underscore like IRB-1600-1.2 -> irb_1600_1_2?

Or should we ommit the dot entirely IRB-1600-1.2 -> irb_1600_12?

I would go for the first one.

See ros-industrial/ros_industrial_issues#22.

See ros-industrial/ros_industrial_issues#23.

As per subject.

Starting with Hydro, this will result in warnings of deprecation being printed.

roscpp and moveit_core are listed as both DEPENDS and CATKIN_DEPENDS. They are actually catkin packages, and should only be under CATKIN_DEPENDS.

The irb_5400 is modeled as a 6-Joint 6-DOF manipulator. The wrist in fact has a mimic joint, making it a 7-Joint 6-DOF manipulator. The last joint and corresponding link models are currently incorrect.

As per subject.

Even though the driver now defaults to false for the J23_coupled parameter, the correct value should still be added to (or at least documented in) the appropriate launch files in the IRB 5400 support package.

See ros-industrial/ros_industrial_issues#20.

See also ros-industrial/motoman#57 and ros-industrial/fanuc#142.

It would useful to get a Kinetic release out the door. Currently the Moveit-IKFast plugin will not build w/o the inclusion of c++11 flags.

The IRB 2400 xacro (abb_common/urdf/irb_2400_macro.xacro) does not have the prefix argument in front of the link names under the joint declarations. This means than any macro use with a defined prefix will create an invalid macro.

• This is also incorrect in the hydro branch

I was looking for a way to teleoperate the irb-1600 in our lab and I looked into writing some servers to get the robot status. It's fairly simple to add RobotStatus msg to the existing server, provided some EIO.cfg tweaking inside the IRC-5.

On the stateServer (IRC-5) side we need to add:

• A virtual I/O unit to declare some status Digital Outputs and connect them to the corresponding System Output (ref: IRC-5 System Parameters Manual, Topic I/O, Type System Output):
  • /RobotMode mode reporting: Use Auto On (Auto mode when 1, Manual or Manual 100% when 0)
  • /TriState e_stopped reporting: Use Emergency Stop (1 when EStop, 0 Otherwhise) possibly in combination with Run Chain OK
  • /TriState drives_powered reporting: Use Motors ON State (1 when Drivers are enabled, 0 otherwise), take note that breakes are not released until the manipulator moves for the first time.
  • /TriState motion_possible reporting: This is a bit tricky, we need a combination of Motors ON State, Task Executing (with Argument2 set to the motion task executing ROS movements) and Cycle On.
  • /TriState in_motion reporting: use Mechanical Unit Not Moving (0 when moving, 1 otherwise), according to documentation this signal is down if the task is executing but the manipulator is steady (i.e. TCP Speed is 0).
  • /TriState in_error: use Execution Error for just errors in the program.

In the client side is all already there as the abb_robot_state_node runs a RobotStateInterface.

Fix the visual meshes shading to get smooth lightning:
http://answers.ros.org/question/226831/how-do-i-make-my-meshes-appear-shaded/

Collisions meshes should not be edited.

From abb_drivers package manifest (here):

  <build_depend>industrial_robot_client</build_depend>
  <build_depend>simple_message</build_depend>

  <run_depend>industrial_robot_client</run_depend>

The run_depend on industrial_robot_client will transitively pull in the simple_message run_depend, but it's unclear why the build_depend then is listed separately.

The build_depend on simple_message can probably be removed.

From ROS Answers: How do I specify which packages are needed to run code in a package or build packages?.

As per subject, but I don't know whether that directory should be installed. It only contains a abb_utils.h file, with no corresponding library.

Perhaps the abb_common pkg shouldn't export its include dirs, as abb_utils.cpp is only used internally.

Hi!

I am in charge of Hydro packaging for Arch Linux, and several users told me they were interested in abb. However, none of the packages have been released apparently. Is there any particular reason for that? If not, would it be possible to release the packages with bloom?

Thanks!

As per subject. The catkin_package(..) invocation in CMakeLists.txt in abb_common does not list its CATKIN_DEPENDS.

Currently I am using MoveIt! to plan motion paths for the irb120. It works fine and uploads the 20 or so points to the robot, which then performs the movements.

The irb120 can move fine on it's own though, without the help of ROS or MoveIt!. So I feel as if MoveIt! plans the path, sends the points to the ABB controller, which then uses the points to replan it's own path. If this is so, wouldn't it be possible to just send a single point to the robot and let the robot controller (IRC5) figure out it's own path?

Is the path provided by MoveIt! in most cases superfluous and only usefull in situations where an object not known to the robot itself needs to be avoided?

I hope my question is clear.

With kind regards,

Tim

Seems config/joint_limits.yaml has 1.0 as the value for all the max_velocity fields. I seem to remember that was an issue with the MoveIt Setup Assistant some time ago. The newer config for the 6640 does have the correct limits for that robot.

There is/was some ambiguity in the ROS-Industrial documentation about the tool0 frame (see here). The original intent of tool0 was to match exactly (pose & orientation) of the robot tool0. This would allow a comparison between ROS-I reported positions and controller positions for tool0. However, due to conflicting requirements for creating URDF (i.e. a preferred orientation of frames), the tool0 has not always matched the robot controller frame.
Reference: #31