ros-industrial / motoman

ROS-Industrial Motoman support (http://wiki.ros.org/motoman)

Motoman

ROS-Industrial Motoman metapackage. See the ROS wiki page for more information.

The motoman_experimental repository contains additional packages.

ROS 2

This repository hosts the ROS 1 version of MotoROS. If you are looking for ROS 2 support, please visit Yaskawa-Global/motoros2.

Contents

Branch naming follows the ROS distribution they are compatible with. -devel branches may be unstable. Releases are made from the distribution branches (indigo, kinetic).

Older releases may be found in the Github mirror of the old ROS-Industrial subversion repository.

Building

On newer (or older) versions of ROS

Building the packages on newer (or older) versions of ROS is in most cases possible and supported. For example: building the packages in this repository on Ubuntu Xenial/ROS Kinetic, Ubuntu Bionic/ROS Melodic or Ubuntu Focal/ROS Noetic systems is supported. This will require creating a Catkin workspace, cloning this repository, installing all required dependencies and finally building the workspace.

Catkin tools

It is recommended to use catkin_tools instead of the default catkin when building ROS workspaces. catkin_tools provides a number of benefits over regular catkin_make and will be used in the instructions below. All packages can be built using catkin_make however: use catkin_make in place of catkin build where appropriate.

Building the packages

The following instructions assume that a Catkin workspace has been created at $HOME/catkin_ws and that the source space is at $HOME/catkin_ws/src. Update paths appropriately if they are different on the build machine.

These instructions build the kinetic-devel branch on a ROS Kinetic system:

# change to the root of the Catkin workspace
$ cd $HOME/catkin_ws

# retrieve the latest development version of motoman.
$ git clone -b kinetic-devel https://github.com/ros-industrial/motoman.git src/motoman

# check build dependencies. Note: this may install additional packages,
# depending on the software installed on the machine
$ rosdep update

# be sure to change 'kinetic' to whichever ROS release you are using
$ rosdep install --from-paths src/ --ignore-src --rosdistro kinetic

# build the workspace (using catkin_tools)
$ catkin build

Activating the workspace

Finally, activate the workspace to get access to the packages just built:

$ source $HOME/catkin_ws/devel/setup.bash

At this point all packages should be usable (ie: roslaunch should be able to auto-complete package names starting with motoman_..). In case the workspace contains additional packages (ie: not from this repository), those should also still be available.

Installation and usage

Refer to Working With ROS-Industrial Robot Support Packages for information on how to use the files provided by the robot support and MoveIt configuration packages. See also the other pages on the ROS wiki.

Refer to the tutorials for information on installation and configuration of the controller-specific software components.

motoman's Issues

URDFs have an xml extension in motoman_config package

As per the subject: the URDF files in the motoman_config package currently have an .xml extension, which is rather confusing (although technically correct).

They should probably be renamed to the proper .urdf extension.

Dual arm capability release plan

PR #42 & #43 add dual arm control capability to the Motoman packages.

PR #43 contains all changes required for the motoplus/inform (controller side) software
PR #42 contains all changes required for the ROS (pc) software

Before rolling out this capability into the Hydro release, careful consideration must be given to how it could affect the current installations. For example, the controller side software must be matched with appropriate launch parameters on the ROS side (launch parameters enable the ROS side to be backwards compatible). If this is not done correctly, the system could fail to operate after a debian upgrade (with no warning to the user). To address this, a two step release is planned.

The first release, an upgrade to Hydro, will support both controller side server software versions.

• All existing, single arm, robots will utilize the "old" (v1.1) by default software to ensure they continue to work when software is upgraded.
• Any new, dual/single arm, robots will utilize the "new" (v1.2) software by default
• Any new/custom robots created by users will be forced to utilize v1.2 (v1.1 sources/binaries will not be available).
• ROS side software will be configured via launch parameter to work with v1.1 or v1.2 software.
• Initially software will be released as source only (from the hydro-devel branch) to work out any unforseen issues. A debain will only be released if a clean upgrade path can be assured (remains to be seen).
• A wiki will be created to describe the process for creating a dual arm setup (requiring the installation of software from source).

The second release, an Indigo release (~3 months), will only support v1.2 controller side software.

• All robots will utilize v1.2 software (provisions to use v1.1 will be turned off by default or totally removed).
• Wikis will be updated to reflect new installation/configuration procedures for v1.2 software.

sia10f vs sia10d: identical robots?

Aren't the SIA10D and the SIA10F the same robot, just using a different controller?

Should they be merged into a motoman_sia10_support package, with variant specific launch files?

Additional suggestion: should all sia robots be merged into a motoman_sia_support package, which would include the 5(d|f), 10(d|f) and the 20(d|f)?

Error with Motoman SDA10F package

Hello,
When I try the instruction roslaunch motoman_sda10f_moveit_config moveit_planning_execution.launch sim:=true, the next errors appear

[ INFO] [1448860557.614217751]: Loading robot model 'motoman_sda10f'...
[ERROR] [1448860558.119278078]: Group 'torso' is not a chain
[ERROR] [1448860558.119350084]: Kinematics solver of type 'kdl_kinematics_plugin/KDLKinematicsPlugin' could not be initialized for group 'torso'
[ERROR] [1448860558.119792175]: Kinematics solver could not be instantiated for joint group torso.
[ INFO] [1448860558.126523519]: Loading robot model 'motoman_sda10f'...
[ERROR] [1448860558.572781895]: Group 'arms' is not a chain
[ERROR] [1448860558.572861970]: Kinematics solver of type 'kdl_kinematics_plugin/KDLKinematicsPlugin' could not be initialized for group 'arms'
[ERROR] [1448860558.573263572]: Kinematics solver could not be instantiated for joint group arms.
[ INFO] [1448860558.578935053]: Loading robot model 'motoman_sda10f'...
[ERROR] [1448860559.023278249]: Group 'sda10f' is not a chain
[ERROR] [1448860559.023357702]: Kinematics solver of type 'kdl_kinematics_plugin/KDLKinematicsPlugin' could not be initialized for group 'sda10f'
[ERROR] [1448860559.023930325]: Kinematics solver could not be instantiated for joint group sda10f.
[ WARN] [1448860883.486564338]: Failed to call service /get_planning_scene, have you launched move_group? at /tmp/buildd/ros-indigo-moveit-ros-planning-0.6.5-0trusty-20151112-0345/planning_scene_monitor/src/planning_scene_monitor.cpp:461
[ERROR] [1448860575.979981301]: MoveitSimpleControllerManager: Action client not connected: sda10f/sda10f_r1_controller/joint_trajectory_action
[ INFO] [1448860581.096676607]: MoveitSimpleControllerManager: Waiting for sda10f/sda10f_b1_controller/joint_trajectory_action to come up
[ INFO] [1448860586.096886543]: MoveitSimpleControllerManager: Waiting for sda10f/sda10f_b1_controller/joint_trajectory_action to come up
[ERROR] [1448860591.097130984]: MoveitSimpleControllerManager: Action client not connected: sda10f/sda10f_b1_controller/joint_trajectory_action
[ INFO] [1448860596.225098638]: MoveitSimpleControllerManager: Waiting for sda10f/sda10f_b2_controller/joint_trajectory_action to come up
[ INFO] [1448860601.225290651]: MoveitSimpleControllerManager: Waiting for sda10f/sda10f_b2_controller/joint_trajectory_action to come up

So, I can't plan trajectories.

I posted this question here http://answers.ros.org/question/221714/error-with-motoman-sda10f-package/

How can I solve it?

Thank you

sia5d_support: xacro macro refers to files in deprecated 'motoman_config' package

Current version of sia5d_macro.xacro still refers to mesh files in the motoman_config package (here fi).

This would make sia5d_macro.xacro stop working as soon as #76 is fixed.

Update FS100/DX100 related documentation

The FS100(groovy_devel) and DX100(groovy) were merged when the motoman controller side code became compatible with the DX100. The following pages will have to be updated to reflect that change:

http://ros.org/wiki/fs100
http://ros.org/wiki/dx100
http://ros.org/wiki/motoman/Tutorials

moveit_cfgs: missing run_depend on industrial_robot_simulator

See ros-industrial/ros_industrial_issues#23.

sia20: incorrect T->tool0 rotation (pi != 3.1416)

The link_t-tool0 transform defining the orientation of the tool0 frame currently specifies only a rotation over Z of -pi, but it uses the value 3.1416 for it (here).

The difference is enough to cause the base->tool0 transform to be off by as much as 3 degrees wrt to the values reported by the robot.

Controller not in REMOTE mode (5005)

The MotoPlus application looks at the internal signal #50056 to detect if the pendant is in REMOTE mode. On European FS100 (or at least the one I have here in Denmark), the signal does not change when the key is turned to REMOTE. The control signal #80011 does on the other hand change.

Eric Marcil have verified this and mailed me a recompiled version where the control signal #80011 is used to detect wether the pendant is in REMOTE mode, but the change does not seem to have propagated to github yet.
Please remember to include the change in this official version as well, to make this great package usable in Europe as well.

build fails: motoman_driver missing motoman_msgs dependencies

Clone motoman repo to a bare catkin workspace, with no pre-installed motoman packages. Run catkin_make, and build fails with the following error:

In file included from /home/ros-industrial/ros/src/motoman/motoman_driver/src/industrial_robot_client/joint_relay_handler.cpp:37:0:
/home/ros-industrial/ros/src/motoman/motoman_driver/include/motoman_driver/industrial_robot_client/joint_relay_handler.h:47:45: fatal error: motoman_msgs/DynamicJointsGroup.h: No such file or directory
 #include "motoman_msgs/DynamicJointsGroup.h"
                                             ^

Looks like the CMakeLists.txt in motoman_driver is missing some dependencies on motoman_msgs targets. I confirmed that motoman_msgs is not being built prior to the error, and that the message header files are not being generated.

I have a fix with the required dependencies added, and will submit a pull-request shortly.

Missing install targets

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

Robot specific launch files are missing.

Launch files specific to the different Motoman robots are missing. The fanuc utilizes robot specific packages (which makes it much more user friendly).

The robot specific files can be used to set parameters that would otherwise have to be set by the user. This is not at all apparent and leads to issues/questions ( see: http://answers.ros.org/question/100916/setup-industrial-package-for-use-of-motoman-driver-interface-with-dx100-motoplus/ ).

Populate maintainer name tag in package xml

The mh5 (and perhaps others too) does not have the maintainer name tag populated. See 24b5c23#commitcomment-5429657

Note, this may require updating the package auto-generation tools in https://github.com/ros-industrial/motoman_experimental

Release into Indigo

Would remove the need to build packages from source.

• Remove motoman_config pkg (#76)
• fixup sia5d_support xacro macro (refers to files in motoman_config)

sia10f: urdf out of sync with xacro macro

Minor (as most users would use the .xacro or _macro.xacro file), but the urdf shipped in motoman_sia10f_support (here) is significantly out of sync with the corresponding xacro macro in the same package (here).

Joint names don't match, links are missing, etc.

It should either be updated, or the urdf should be removed from the package.

sia20: incorrect B-T translation?

According to the spec sheet (old link), the translation between joint_b and joint_t should be 208 mm. The motoman_sia20d macro currently has this at 180 mm (here).

This discrepancy of 28 mm is also not fixed-up in the link_t-tool0 transform (which is a zero-transform in the macro).

motoman metapackage does not buildtool-depend on catkin

As per the subject: package.xml is missing a buildtool depend on catkin.

sia10(d|f)_support: incorrect joint limits (s, r & t)

The position limits for joint_s, joint_r and joint_t are specified as (-)3.1416 for the SIA10 in sia10d_macro.xacro, which is incorrect (here for joint_t fi). The spec sheet has these at (-)180 degrees, which would be exactly pi.

It would appear the values in the urdf are rounded up, while they should'be been either floored or written out with more digits.

Add support for DX200 controller

Blocking on PR #42, #43 and ros-industrial/industrial_core#82.

• Update launch files in driver package to support new controller type (add new controller specific launch file and verify byte ordering)
• Update wikis

cfg: suspicious effort=100 in all xacros

All included xacros in motoman_cfg specify an effort limit of 100 for all joints. I'm wondering whether those values are based on any real limits, or are merely 'placeholders'.

I'm not sure what would be better values, but 0 seems to be used in cases where actual limits are unknown (this should be verified).

Package SIA20D_Mesh_arm_navigation is not following naming conventions

Upon invoking catkin_make with the motoman stack in the workspace shows:

WARNING: Package name "SIA20D_Mesh_arm_navigation" does not follow the naming conventions. It should start with a lower case letter and only contain lower case letters, digits and underscores.

SIA20d MoveIt package complains about database file permissions.

When loading a moveit config package (Hydro debian), the following error is thrown due to a database file permissions issue:

[ INFO] [1411442111.897502369]: Loading robot model 'motoman_sia20d'...
Traceback (most recent call last):
  File "/opt/ros/hydro/lib/warehouse_ros/mongo_wrapper_ros.py", line 93, in <module>
    os.makedirs(dbpath)
  File "/usr/lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/opt/ros/hydro/share/motoman_sia20d_moveit_config/default_warehouse_mongo_db'
[mongo_wrapper_ros_ROS_22581_186060070-7] process has died [pid 22719, exit code 1, cmd /opt/ros/hydro/lib/warehouse_ros/mongo_wrapper_ros.py __name:=mongo_wrapper_ros_ROS_22581_186060070 __log:=/home/ros/.ros/log/d31c69b8-42cf-11e4-969f-080027f3243a/mongo_wrapper_ros_ROS_22581_186060070-7.log].
log file: /home/ros/.ros/log/d31c69b8-42cf-11e4-969f-080027f3243a/mongo_wrapper_ros_ROS_22581_186060070-7*.log
[ INFO] [1411442112.415595818]: Publishing maintained planning scene on 'monitored_planning_scene'

driver: constants and defaults

• Alert user when using constants and defaults.
• Check redefinition of constants. Example: MAX_NUM_GROUPS is defined in both joint_feedback_ex.h and joint_traj_pt_full_ex.h

driver: incorrectly listing catkin pkgs as DEPENDS instead of CATKIN_DEPENDS

In CMakeLists.txt of motoman_driver:

catkin_package(
    DEPENDS std_msgs roscpp actionlib trajectory_msgs actionlib_msgs
            control_msgs sensor_msgs simple_message urdf industrial_msgs
            industrial_robot_client simple_message
    CATKIN_DEPENDS 
    INCLUDE_DIRS include
    LIBRARIES 
)

At least some (if not all?) packages listed as DEPENDS should actually be CATKIN_DEPENDS (see also wiki.ros.org/catkin/CMakeLists.txt#catkin_package).

FS 100 response to MOTO_MOTION_CTRL message incorrect.

The robot id and sequence fields in the MOTO_MOTION_CTRL reply are not set correctly. See the email snippet below for more details.

On 12/06/2013 20:01, Zoss, Jeremy K. wrote:

Gijs,

I was not involved in the earlier email chain, so I don't have a copy
of the Wireshark capture. When I look through the MotoPlus source
code, I think I can see where this reply is coming from. See
fs100/MotoPlus/SimpleMessage.c:Ros_SimpleMsg_MotionReply()
http://code.google.com/p/swri-ros-pkg/source/browse/trunk/motoman/fs100/MotoPlus/SimpleMessage.c#92.
In the code, it looks like when a reply message is sent to anything
other than a MOTO_MOTION_CTRL message (type 2001), the robot_id and
sequence fields are set to -1. This probably comes across as 0xFFFFFFFF.

Yes, -1 interpreted as an unsigned would be 0xFFFFFFFF.

I don’t know that this behavior was intended or not. In particular,
the tests at lines 106 and 112 seem redundant. I agree with you that
the expected reply to a JointTrajPtFull message should mirror the
robot_id and sequence from the incoming message. I think your
interpretation of the expected response is correct.

Looks like a copy/pasta error to me then. The 'else if' checks again for a ROS_MSG_MOTO_MOTION_CTRL, just as the 'if' before it did.

This should be a simple 3-line change, but I’ll check with the Motoman
author first to see if he has any objections.

Ok.

If I get the dissector in a good enough state, I'll push it to my github
repo.

Gijs

driver: illegal values for 'valid_fields' field in simple message binary stream

Just noticed this while analysing some Wireshark captures of simple message traffic between the currently released motion_streaming_interface and a controller (exact type of the controller has no impact on the occurrence of the problem).

From the capture:

ROS-Industrial SimpleMessage, Motoman Joint Trajectory Point Full Extended (0x7e0), 288 bytes, big-endian
    Prefix
        Packet Length: 284
    Header
        ...
        Communications Type: Service Request (2)
        ...
    Body
        ...
        Group 0
            ...
            Valid Fields: 0x159e10f (Position, Time, Acceleration, Velocity)
                .... ...1 = Time         : Valid (1)
                .... ..1. = Position     : Valid (1)
                .... .1.. = Velocity     : Valid (1)
                .... 1... = Acceleration : Valid (1)
            Time: 1.08976
            ...
        ...

Note the 0x159e10f value for Valid Fields.

Only the lower four bit positions in the valid_fields field of the JOINT_TRAJ_PT_FULL_EX message type are defined, with all of the others reserved for future use (see Message Structures of the ROS-Industrial Simple Message Protocol - Defined Constants - Valid Fields).

I'm not sure if this actually leads to any problems (that would depend on how the valid_fields field is actually assigned its value), but it violates the protocol specs in any case and should be fixed.

sia20d_support: incorrect joint limits (s, r & t)

The position limits for joint_s, joint_r and joint_t are specified as (-)3.1416 for the SIA20 in sia20d_macro.xacro, which is incorrect (here for joint_t fi). The spec sheet has these at 180 degrees, which would be exactly pi.

It would appear the values in the urdf are rounded up, while they should'be been either floored or written out with more digits.

Improve meshes shading

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.

driver: persistent (and incorrect) "Trajectory start position doesn't match current robot position"

observed behaviour: when trying to execute a trajectory through the motoman_driver provided joint_trajectory_action node, the motoros application persistently returns a MotionReplySubcodes::Invalid::DATA_START_POS error, even if target_pos == current_pos for all joints. Analysis of the simple message traffic between motoros and the ROS PC confirmed the receipt of the DATA_START_POS error message.

Starting the servos before commanding a motion does not help (to avoid running into issues with START_MAX_PULSE_DEVIATION and gravity).

The work-around for #91 also does not influence this.

expected: execution of the trajectory

sia10f_moveit_cfg: missing run_depend on industrial_robot_simulator

Same as #32.

Also for ros-industrial/ros_industrial_issues#23.

ROS launch tests fail on indigo-devel branch

ROS launch test fail under indigo because the "version0" argument is not set by the calling launch files. "version0" allows indigo client nodes to be run with a pre-indigo robot server.

driver: enhance documentation quality

• Refine comments inside code
• tutorial that describes the process of creating a dual arm system. To be placed at: http://wiki.ros.org/motoman_driver/Tutorials
  For reference, it should probably follow the process of this tutorial: http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot

driver: hard coded Python path

See ros-industrial/ros_industrial_issues#9.

mh5: Binary STL meshes begin with "solid" (they shouldn't)

Head's up, ASCII STL files are supposed to be designated by the first 5 lines reading "solid" in ASCII. The following binary STL files start with "solid" and they shouldn't. I'm pretty sure this is something that the SolidWorks STL exporter does. It should be sufficient to replace "solid" with some other five characters like "hello".

> grep -r -A 1 ^solid *                     (hydro-devel) 
Binary file mh5/visual/MH5_T_AXIS.stl matches
Binary file mh5/visual/MH5_L_AXIS.stl matches
Binary file mh5/visual/MH5_R_AXIS.stl matches
Binary file mh5/visual/MH5_BASE_AXIS.stl matches
Binary file mh5/visual/MH5_S_AXIS.stl matches
Binary file mh5/visual/MH5_U_AXIS.stl matches
Binary file mh5/visual/MH5_B_AXIS.stl matches

ref: https://en.wikipedia.org/wiki/STL_(file_format)#Binary_STL

driver: assertion in joint_relay_handler when controller has < 4 motion groups configured

As reported in #89: the code hits the following assertion quickly after connecting to a controller:

[FATAL] [1463490740.608713916]: ASSERTION FAILED
    file = /path/to/src/motoman/motoman_driver/src/industrial_robot_client/joint_relay_handler.cpp
    line = 322
    cond = all_joint_state.positions.size() == all_joint_names.size()

Observed on a system with an FS100 with two motion groups:

1. SIA20
2. linear track

motoman_driver based on the code in #89.

support: tool0 needed for URDFs

Request tool0 be added to each robot, and URDFs updated.

Mixed case directory names in fs100 package

As per subject: the Inform and MotoPlus directories are mixed case, all other directories are lowercase. The dx100 package has directories with the same names, but in all lowercase.

driver: improve ambiguous logging messages

Provide group information for every debugging message. E.g. JointFeedbackRelayHandler::convert_message(.., int robot_id)

support: add 'base' coordinate system link to URDFs

As discussed in ros-industrial/ros_industrial_issues#24.

Remove motoman_config pkg before releasing into Indigo

has been deprecated for quite some time now already.

support: missing run_depend on industrial_robot_client

Even though the support packages use the custom nodes in motoman_driver, the files in launch/ still depend on industrial_robot_client, as they use the config/robot_state_visualize.rviz file.

sia5d urdf doesn't have move-able joints

The sia5d urdf doesn't have movable joints when viewed in the urdf_tutorial:

roslaunch urdf_tutorial display.launch model:=sia5d.urdf gui:=true

This is due to safety controller limits in the urdf (these should be removed)

<safety_controller k_position="0" k_velocity="0" soft_lower_limit="0" soft_upper_limit="0"/>

driver: no tests for motoman-specific simple_message and IRC extensions

The simple_message and industrial_robot_client packages have a number of tests to make sure the (de)serialisation and data structure classes work as they are supposed to. While the motoman_driver package has introduced a number of motoman-specific extensions to that infrastructure, it did not also introduce tests for them.

Based on our experience with the tests in simple_message, issues like #91 are examples of problems that would most likely have been uncovered by a solid test set.

This situation should be rectified and tests for at least the set of simple messages implemented in this package should be added.

motoman_driver: driver flags trajectory completion too soon

The fs100 controller driver seems to return a completion result for a trajectory even though the robot is still moving towards the goal position. This issue was observed when I sent a new trajectory with the "execute" method of the moveit move_group interface. The driver error message complained about the start state differing from the current state and then the node running the move_group interface would quit. My application only uses locking motion methods (move() and execute() ), which should theoretically prevent situations where a new trajectory is sent while another trajectory is being consumed.

driver: no recovery after trying to execute a trajectory in TEACH mode

[/motion_streaming_interface: motion_ctrl::MotomanMotionCtrl::setTrajMode: 86 ERROR] [1466091365.051498907]: Failed to set TrajectoryMode: Not Ready (5) : Controller in TEACH mode (5004)
[/motion_streaming_interface: joint_trajectory_streamer::MotomanJointTrajectoryStreamer::send_to_robot: 326 ERROR] [1466091365.051527535]: Failed to initialize MotoRos motion.  Trajectory ABORTED.  Correct issue and re-send trajectory.

When the driver is started with the robot in teach mode and we try to move the robot this error occurs as expected, but if we then put the controller in remote mode, the driver doesn't recover and needs to be restarted.

driver: not linking against catkin_LIBRARIES

Trying to build the motoman_driver package using catkin_make_isolated results in:

Linking CXX executable /home/user/ros/industrial_hydro/devel_isolated/motoman_driver/lib/motoman_driver/motion_streaming_interface
/usr/bin/ld: CMakeFiles/motoman_motion_streaming_interface.dir/src/joint_streaming_node.cpp.o: undefined reference to symbol 'ros::init(int&, char**, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'
/usr/bin/ld: note: 'ros::init(int&, char**, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)' is defined in DSO /opt/ros/hydro/lib/libroscpp.so so try adding it to the linker command line
/opt/ros/hydro/lib/libroscpp.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [/home/user/ros/industrial_hydro/devel_isolated/motoman_driver/lib/motoman_driver/motion_streaming_interface] Error 1
make[1]: *** [CMakeFiles/motoman_motion_streaming_interface.dir/all] Error 2
make: *** [all] Error 2

This seems to be due to not linking against catkin_LIBRARIES.

Moveit config packages missing dependency on moveit-simple-controller-manager

When installing ros-industrial packages individually (i.e. without first installing moveit or ros-industrial-desktop), the moveit-simple-controller-manager package is not installed.

driver: suspicuous magic nr (3) in JointTrajectoryAction::withinGoalConstraints(..)

I'm not sure I completely understand the flow of control in JointTrajectoryAction, but it would appear JointTrajectoryAction::withinGoalConstraints(const control_msgs::FollowJointTrajectoryFeedbackConstPtr &msg, const motoman_msgs::DynamicJointTrajectory & traj) (here) compares the current state of a group's trajectory execution with the positions vector of the 4th group, irrespective of the group for which it has been passed joint states or a trajectory (here).

Excerpt:

...
else
{
    int last_point = traj.points.size() - 1;

    const motoman_msgs::DynamicJointsGroup &pt = traj.points[last_point].groups[3];

    int group_number = pt.group_number;

    if (industrial_robot_client::utils::isWithinRange(
          last_trajectory_state_map_[group_number]->joint_names,
          last_trajectory_state_map_[group_number]->actual.positions, traj.joint_names,
          traj.points[last_point].groups[3].positions, goal_threshold_))
    {
      rtn = true;
    }
...

Note the magic nr 3 two times in this.

At leas the magic nr would need to be explained, but I'm rather curious how this would work on systems with > 1 and < 4 groups.

Joint Names Convention

Check the feasibility of changing back the joint names for the SDA10F and SIA10F from motoman_joint_N_L to motoman_joint_L

SDA5F: controller is taking too long to execute

Hello,

I. I'm working with a SDA5F robot, and I can realize the motion planning function with MoveIt. However, when I executed the planned path, some problems came up:

When I chose the single arm groups (arm_left & arm_right), the robot performed well;
But when I chose the sda10f group (for all joints of SDA5F), the robot could follow the path, but MoveIt cannot receive the /joint_trajectory_action/result topic, and return the error codes:

Controller is taking too long to execute trajectory (...). Stopping trajectory.
Execution completed: TIMED_OUT
Transitioning goal to LOST

and then moveit breakdown.

II. Besides, I have another question, Could the motoman_driver realize the Jacobian basd control (speed control, differential control or something like that)? I have tested the /joint_path_command and controlled the joint_t from curPosition to curPosition+dq in each iteration. the joint_t of robot could move, but it would stop in each iteration.
Or, can I direct control the joint velocity through this package?

Thanks a lot!