As per subject: the launch directory only contains launch files for the default versions of robot_state, motion_streaming_interface etc.

Perhaps these should be added? Alternatively we could parameterise them, similar to the launch files in the robot support packages (ie: use_bswap etc).

As per issue title. Not sure if intentional or not.

Packages missing one:

• simple_message
• industrial_robot_client
• industrial_msgs
• industrial_utils

Seems the industrial_core metapackage is missing a CMakeLists.txt, which then leads it to complain about a 'non-homogeneous' workspace (which is odd, considering the non-present CMakeLists.txt causes just a warning earlier, not an error).

Copying the generated CMakeLists.txt to industrial_core/industrial_core solved it.

Note: this only failed on the first invocation of catkin_make (ie: after a fresh clone). Subsequent invocations did not fail, even after I removed the generated CMakeLists.txt.

See also catkin metapackage now requires CMakeLists.txt? on ROS Answers.

According to the Installing section of the Building and installing C++ libraries and headers page of the catkin documentation, library targets should be installed using:

install(TARGETS your_library
        ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
        LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
        RUNTIME DESTINATION ${CATKIN_GLOBAL_BIN_DESTINATION})

At least industrial_robot_client and simple_message do not do this. This should be corrected.

The current wiki page of the industrial_robot_client package shows the typical content (intro, toc, overview), but then immediately 'goes deep' (ie Modification for Robot-Specific Needs).

I'd expect to find an overview of the node api there -- similar to the industrial_robot_simulator page -- but that information is under the 'this page' link.

Perhaps this could be reversed? Move the Node API to the landing page, and place the more in-depth information on a separate page.

Trying to build fanuc_driver against the recent Hydro release (0.3.3) fails with:

Linking CXX executable /home/user/ros/industrial_hydro/devel_isolated/fanuc_driver/lib/fanuc_driver/motion_streaming_interface
/usr/bin/ld: CMakeFiles/fanuc_driver_motion_streaming_interface.dir/src/fanuc_joint_streamer_node.cpp.o: undefined reference to symbol 'industrial::tcp_client::TcpClient::TcpClient()'
/usr/bin/ld: note: 'industrial::tcp_client::TcpClient::TcpClient()' is defined in DSO /home/user/ros/industrial_hydro/devel_isolated/simple_message/lib/libsimple_message.so so try adding it to the linker command line
/home/user/ros/industrial_hydro/devel_isolated/simple_message/lib/libsimple_message.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

I seem to remember this worked under rosbuild because simple_message built static libraries, whereas it currently builds shared libraries (the default under catkin / CMake).

Adding the STATIC argument to the add_library() statements in simple_message/CMakeLists.txt results in the old behaviour. I'm not sure that is what we want though.

Normally, catkin would recursively collect all required libraries (and link against simple_message.so and industrial_robot_client.so automatically), but simple_message breaks this (see #46), hence the need to list both libraries manually in target_link_libraries(..).

The industrial trajectory filters package from industrial experimental should be migrated to industrial core in preparation for the hydro release.

The package xml/dox files should also be update in preperation for release (i.e. fill out descriptions, add install targets, etc...).

The package will have to be added to the industrial_core metapackage.

ie:

<export>
  <cpp lflags="-Wl,-rpath,${prefix}/lib -L${prefix}/lib" cflags="-I${prefix}/include -DROS=1"/>
</export>

This is no longer supported in catkin. Exporting include and linker paths as well as libraries to link against should be done using the catkin_package(..) statement.

At least simple_message, industrial_robot_client, industrial_utils and industrial_simulator do this.

The TCP test in the Message Manager test suite ( https://github.com/ros-industrial/industrial_core/blob/groovy-devel/simple_message/test/utest.cpp#L486 ) requires roscore in order to complete. This prevents the simple message unit test from running on the Jenkins build system. In order to enable automatic testing (and failure reporting), this test should be disabled. Note: a more permanent solution would be to role this test into a rostest suite (i.e. one that automatically starts roscore and performs the required tests). This should be considered in the future.

This is identical to #4, but under Groovy. Checking out the groovy-devel branch and trying to catkin_make it results in the exact same errors as under Hydro.

Seems genmsg has been updated on Groovy to also require the use of pkg_name_EXPORTED_TARGETS.

Related issue on ros/genmsg.

Currently, the simple_message receive calls will block forever until the requested message data is received or the connection is dropped/reset. For some applications, it may be helpful for the user to be able to specify a timeout on the socket-read.

The recent fix to Issue #25 helps provide some of the low-level socket structure needed for this enhancement. But, this enhancement will require additional changes to the higher-level messaging layers to pass the timeout error status up to user-level code.

While looking into Rename JOINT_NAMES in ur_driver test_move.py on ROS Answers:

I've observed that joint_trajectory_action::withinGoalConstraints(..) tries to dereference the last_trajectory_state_ member variable in a call to industrial_robot_client::utils::isWithinRange(..), even when no FollowJointTrajectoryFeedback has ever been received.

Sending a goal to the joint_trajectory_action node "too early" (ie: JointTrajectoryAction::controllerStateCB(..) has not been invoked) then results in a segfault.

Backtrace:

[1413970334.414501639] [ INFO] [/joint_trajectory_action]: Received new goal
joint_trajectory_action: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = const control_msgs::FollowJointTrajectoryFeedback_<std::allocator<void> >]: Assertion `px != 0' failed.

Program received signal SIGABRT, Aborted.
0xb7fdf1b2 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0  0xb7fdf1b2 in ?? () from /lib/ld-linux.so.2
#1  0xb7a81e0f in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb7a85455 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xb7a7acb5 in ?? () from /lib/i386-linux-gnu/libc.so.6
#4  0xb7a7ad67 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6
#5  0x080c7a6d in boost::shared_ptr<control_msgs::FollowJointTrajectoryFeedback_<std::allocator<void> > const>::operator-> (this=0xbfffe838)
    at /usr/include/boost/smart_ptr/shared_ptr.hpp:418
#6  0x080bf571 in industrial_robot_client::joint_trajectory_action::JointTrajectoryAction::withinGoalConstraints (this=0xbfffe650, msg=..., traj=...)
    at /home/user/ros/answers_test_hydro/src/industrial_core/industrial_robot_client/src/joint_trajectory_action.cpp:293
#7  0x080bd1dc in industrial_robot_client::joint_trajectory_action::JointTrajectoryAction::goalCB (this=0xbfffe650, gh=...)
    at /home/user/ros/answers_test_hydro/src/industrial_core/industrial_robot_client/src/joint_trajectory_action.cpp:132
#8  0x080d8db3 in boost::_mfi::mf1<void, industrial_robot_client::joint_trajectory_action::JointTrajectoryAction, actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >&>::operator() (this=0xbfffe6f8, p=0xbfffe650, a1=...)
    at /usr/include/boost/bind/mem_fn_template.hpp:165
#9  0x080d738e in boost::_bi::list2<boost::_bi::value<industrial_robot_client::joint_trajectory_action::JointTrajectoryAction*>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, industrial_robot_client::joint_trajectory_action::JointTrajectoryAction, actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >&>, boost::_bi::list1<actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >&> > (this=0xbfffe700, f=..., a=...) at /usr/include/boost/bind/bind.hpp:313
#10 0x080d4fb1 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, industrial_robot_client::joint_trajectory_action::JointTrajectoryAction, actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >&>, boost::_bi::list2<boost::_bi::value<industrial_robot_client::joint_trajectory_action::JointTrajectoryAction*>, boost::arg<1> > >::operator()<actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > > > (this=0xbfffe6f8, a1=...) at /usr/include/boost/bind/bind_template.hpp:32
#11 0x080d24ce in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf1<void, industrial_robot_client::joint_trajectory_action::JointTrajectoryAction, actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >&>, boost::_bi::list2<boost::_bi::value<industrial_robot_client::joint_trajectory_action::JointTrajectoryAction*>, boost::arg<1> > >, void, actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > > >::invoke (function_obj_ptr=..., a0=...)
    at /usr/include/boost/function/function_template.hpp:153
#12 0x080d2cb4 in boost::function1<void, actionlib::ServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > > >::operator()
    (this=0xbfffe6f4, a0=...) at /usr/include/boost/function/function_template.hpp:1013
#13 0x080ceb32 in actionlib::ActionServerBase<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >::goalCallback (this=0xbfffe694, 
    goal=...) at /opt/ros/hydro/include/actionlib/server/action_server_base.h:252
#14 0x080dd62e in boost::_mfi::mf1<void, actionlib::ActionServerBase<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>::call<actionlib::ActionServer<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const> (
    this=0x8125b9c, u=@0x8125ba4: 0xbfffe694, b1=...) at /usr/include/boost/bind/mem_fn_template.hpp:156
#15 0x080dc515 in boost::_mfi::mf1<void, actionlib::ActionServerBase<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>::operator()<actionlib::ActionServer<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*> (this=0x8125b9c, u=@0x8125ba4: 0xbfffe694, a1=...) at /usr/include/boost/bind/mem_fn_template.hpp:171
#16 0x080da7c6 in boost::_bi::list2<boost::_bi::value<actionlib::ActionServer<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, actionlib::ActionServerBase<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>, boost::_bi::list1<boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&> > (this=0x8125ba4, f=..., a=...) at /usr/include/boost/bind/bind.hpp:313
#17 0x080d8f49 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, actionlib::ActionServerBase<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>, boost::_bi::list2<boost::_bi::value<actionlib::ActionServer<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*>, boost::arg<1> > >::operator()<boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> > (this=0x8125b9c, a1=...) at /usr/include/boost/bind/bind_template.hpp:47
#18 0x080d7820 in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf1<void, actionlib::ActionServerBase<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>, boost::_bi::list2<boost::_bi::value<actionlib::ActionServer<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*>, boost::arg<1> > >, void, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>::invoke (
    function_obj_ptr=..., a0=...) at /usr/include/boost/function/function_template.hpp:153
#19 0x080dc79c in boost::function1<void, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&>::operator() (this=0x8125b98, a0=...) at /usr/include/boost/function/function_template.hpp:1013
#20 0x080da92c in boost::detail::function::void_function_obj_invoker1<boost::function<void (boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&)>, void, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> >::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const>) (
    function_obj_ptr=..., a0=...) at /usr/include/boost/function/function_template.hpp:153
#21 0x080e1f66 in boost::function1<void, boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> >::operator() (
    this=0x8125a14, a0=...) at /usr/include/boost/function/function_template.hpp:1013
#22 0x080e01b7 in ros::SubscriptionCallbackHelperT<boost::shared_ptr<control_msgs::FollowJointTrajectoryActionGoal_<std::allocator<void> > const> const&, void>::call (this=0x8125a10, params=...) at /opt/ros/hydro/include/ros/subscription_callback_helper.h:140
#23 0xb7ea42b7 in ros::SubscriptionQueue::call() () from /opt/ros/hydro/lib/libroscpp.so
#24 0xb7e55297 in ros::CallbackQueue::callOneCB(ros::CallbackQueue::TLS*) () from /opt/ros/hydro/lib/libroscpp.so
#25 0xb7e56da4 in ros::CallbackQueue::callAvailable(ros::WallDuration) () from /opt/ros/hydro/lib/libroscpp.so
#26 0xb7ea7a78 in ros::SingleThreadedSpinner::spin(ros::CallbackQueue*) () from /opt/ros/hydro/lib/libroscpp.so
#27 0xb7e8c097 in ros::spin(ros::Spinner&) () from /opt/ros/hydro/lib/libroscpp.so
#28 0xb7e8c0c8 in ros::spin() () from /opt/ros/hydro/lib/libroscpp.so
#29 0x080bb1bb in industrial_robot_client::joint_trajectory_action::JointTrajectoryAction::run (this=0xbfffe650)
    at /home/user/ros/answers_test_hydro/src/industrial_core/industrial_robot_client/include/industrial_robot_client/joint_trajectory_action.h:67
#30 0x080babf2 in main (argc=1, argv=0xbfffe8f4)
    at /home/user/ros/answers_test_hydro/src/industrial_core/industrial_robot_client/src/generic_joint_trajectory_action_node.cpp:42

As per this email to the ros-industrial mailing list: Compiling ros-industrial with catkin_make_isolated.

Building industrial_robot_client using catkin_make_isolated fails with the following error:

==> make -j1 in '/home/user/ros/industrial_groovy_isolated/build_isolated/industrial_robot_client'
Linking CXX shared library /home/user/ros/industrial_groovy_isolated/devel_isolated/industrial_robot_client/lib/libindustrial_robot_client.so
/usr/bin/ld: cannot find -lsimple_message
collect2: ld returned 1 exit status
make[2]: *** [/home/user/ros/industrial_groovy_isolated/devel_isolated/industrial_robot_client/lib/libindustrial_robot_client.so] Error 1
make[1]: *** [CMakeFiles/industrial_robot_client.dir/all] Error 2
make: *** [all] Error 2
<== Failed to process package 'industrial_robot_client': 
  Command '/home/user/ros/industrial_groovy_isolated/devel_isolated/simple_message/env.sh make -j1' returned non-zero exit status 2

This seems to be due to the fact that CMake cannot resolve the reference in target_link_libraries(..) to the target simple_message (which is defined in the simple_message pkg), and tries to link with libsimple_message (no full path).

In a 'normal' catkin_make invocation, all targets share a single namespace, hence CMake can resolve the reference. With catkin_make_isolated all pkgs are build in isolation, the target simple_message doesn't exist in the namespace for industrial_robot_client and the above error is reported.

The industrial deprecated package is meant to ease deprecation of packages within ROS and ROS-Industrial. It should be cleaned of anything that is officially unsupported (these are mostly arm-navigation support) and populated with any new deprecated items (none that I know of).

connection.init(char ) => .init(const char)

I don't see why the IP address in the different client init functions shouldn't be const. I'm having to fix it in my code and there's a hack in joint_trajectory_interface.cpp:60 which also painfully addresses it.

2 participants
JeremyZoss commented 7 days ago

Agreed. There are many other areas in the core libraries that could probably be improved for const-correctness. But these things kind of have a way of cascading to make small changes trigger much larger changes. So, I agree in theory, but we may need to be selective about what code is updated to prevent potentially breaking higher-level code that builds on these libraries.

Seems the CMakeLists.txt is missing an install rule for the planning_request_adapters_plugin_description.xml file in the hydro-devel branch.

The industrial robot simulator should allow using an initial user defined joint state instead of always starting with all the joint values set to 0.

Seems to be due to the catkin_package(... LIBRARIES ..) statement in the CMakeLists.txt for industrial_robot_client.

simple_message has a similar problem, resulting in one target linking with both libsimple_message.so and libsimple_message_bswap.so.

The simple message package is meant to be a source package that is built by setting compile flags. Libraries/binaries are built for the variations used in ROS-Industrial, but a user should also be free to build their own versions. This can be done with the source version, but not easily with the debian version. It might be easier with the debian version if we installed a cmake macro that encapsulated the simple message import and build step.

As per subject line.

Compilation with catkin_make fails with:

/home/user/ros/industrial_hydro/src/industrial_core/simple_message/src/robot_status.cpp:44:39: fatal error: industrial_msgs/RobotMode.h: No such file or directory
compilation terminated

Seems like the industrial_msgs target isn't built before simple_message. Invoking catkin_make --pkg industrial_msgs manually lets a subsequent catkin_make succeed.

On groovy this works as expected (ie: first industrial_msgs is built, then simple_message).

Invoking catkin_make --pkg industrial_deprecated install fails with:

error: package directory 'src/industrial_deprecated' does not exist
CMake Error at catkin_generated/safe_execute_install.cmake:4 (message):

  execute_process(/home/user/ros/industrial_trunk_catkin/build/industrial_core/industrial_deprecated/catkin_generated/python_distutils_install.sh)
  returned error code
Call Stack (most recent call first):
  cmake_install.cmake:36 (INCLUDE)


make: *** [install] Error 1

Upon cloning the industrial_core repo into my catkin workspace, catkin_make gave the following error:

CMake Error at industrial_core/simple_message/CMakeLists.txt:97 (add_dependencies):
  add_dependencies called with incorrect number of arguments

The error appeared three times for the three add_dependencies lines, one example below:

add_dependencies(simple_message_bswap ${industrial_msgs_EXPORTED_TARGETS})

I changed the ${industrial_msgs_EXPORTED_TARGETS} to simple_message_gencpp and was able to complete the make process.
I'm guessing maybe there's a setting/configuration I missed somewhere, but I'm not sure.

See ros-industrial/ros_industrial_issues#9.

Invoking "catkin_make --pkg industrial_robot_simulator install" fails

The implementation of logSocketError(..) in simple_socket.h is naive: the value of errno is retrieved inside the function (see simple_socket.h#L210). Depending on the context in which this function is called, errno could've already changed, making the printed message useless.

A better approach would be to pass errno as a parameter to the logSocketError(..) function, making it the responsibility of the caller to ensure the validity of the errno value.

Identical to #46. See ros-industrial/fanuc#56 for some more info.

We should probably namespace all defines used in the simple_message package, as they are rather generically named right now. Especially INT32, INT64, ROS and LINUXSOCKETS have the potential to clash with defines from other headers / libraries.

I propose to prefix them with something like SIMPLE_MESSAGE_.

Now that we start looking into properly exporting those defines to users of the package as well, this could become a real issue.

See ros-industrial/ros_industrial_issues#8.

Currently, the number of joint-related information that can be transmitted by the joint streaming interface is hard-coded. Being able to specify the number of joint information that can be passed dynamically would greatly increase flexibility of the interface.

MoveIt users have recently released a new controller manager plugin: moveit_simple_controller_manager, intended to be used for robots that do not require complex controller_manager capabilities.

Currently, we use the pr2_controller_manager, with the parameter use_controller_manager set to false. This new plugin would be a cleaner solution, and would reduce an unnecessary dependency on pr2 packages.

We should update the existing moveIt packages and the ROS-I wiki documentation to use this new plugin.

Excerpts from the CMakeLists.txt in simple_message:

target_properties for endianness swapping utest:

set_target_properties(utest_byte_swapping PROPERTIES COMPILE_DEFINITIONS "TEST_PORT_BASE=12000")

target_properties for float64 utest:

set_target_properties(utest_float64 PROPERTIES COMPILE_DEFINITIONS "TEST_PORT_BASE=13000;FLOAT64")

The float64 version repeats the FLOAT64 define in the test target_properties, the byte swapping version does not (no BYTE_SWAPPING in target_properties).

I haven't looked at the actual execution paths influenced by these defines, but is this an omission? Should the utest target_properties for byte swapping also include the define?

Several (i.e. many) users have had issues with socket connection errors to different controllers. When this occurs, the log messages contain the last error code stored in errno. To determine the root cause of the fault, the error code value must be looked up. A better log message should be used the utilizes the strerror() function ( http://linux.die.net/man/3/strerror ). This function returns a string description of error code (presumably similar to comments in error.h).

As far as I understand catkin/what#Python Modules (Libraries) on the ROS wiki, Python scripts no longer need to load the manifest. Ie:

roslib.load_manifest('industrial_robot_simulator')

Is redundant.

When testing the motoman driver, I got this error:

$ rosrun fs100 robot_state
[ INFO] [1374677672.437211315]: Added message handler for message type: 0
[ INFO] [1374677672.440014448]: Robot state connecting to IP address: '192.168.0.101:50241'
[ WARN] [1374677672.440910442]: Unable to find user-specified joint names in 'controller_joint_names'
[ WARN] [1374677672.441766703]: Unable to find URDF joint names in 'robot_description'
[ INFO] [1374677672.441864812]: Using standard 6-DOF joint names: [joint_1, joint_2, joint_3, joint_4, joint_5, joint_6]
[ INFO] [1374677672.442550563]: Connected to server
[ INFO] [1374677672.442607446]: Initializing message manager with default comms fault handler
[ INFO] [1374677672.442657083]: Default communications fault handler successfully initialized
[ INFO] [1374677672.442685145]: Initializing message manager
[ INFO] [1374677672.442726762]: Added message handler for message type: 1
[ INFO] [1374677672.446381376]: Added message handler for message type: 15
[ INFO] [1374677672.447653822]: Entering message manager spin loop
[ERROR] [1374677672.495079875]: Get unload pointer failed, buffer size: 3, smaller than byte size: 4
[ERROR] [1374677672.495149280]: Unload pointer returned NULL
[ERROR] [1374677672.495206461]: Failed to unload message joint: 5 from data[3]
[ERROR] [1374677672.495241827]: Failed to unload joint feedback positions
[ERROR] [1374677672.495278751]: Failed to unload joint feedback message data
[ERROR] [1374677672.495314845]: Failed to initialize joint feedback message
[ERROR] [1374677672.495351389]: Failed to convert SimpleMessage
[ WARN] [1374677672.495409474]: Recieved zero bytes: 0
[ERROR] [1374677672.495445331]: Failed to initialize message
[ERROR] [1374677672.495485843]: Failed to receive incoming message
[ WARN] [1374677672.495522284]: Send failure, no callback support
^C[ INFO] [1374677674.162045284]: Connection failed, attempting reconnect
[ERROR] [1374677674.162110342]: Failed to connect to server, rc: -1, errno: 106
[ WARN] [1374677674.162132291]: Not connected, bytes not sent
[ERROR] [1374677674.162152122]: Failed to receive message length
[ERROR] [1374677674.162164475]: Failed to receive incoming message
[ WARN] [1374677674.162174342]: Send failure, no callback support

When started with DEBUG logging level the ouput.

So, the problem is that the size of the ByteArray returned by receiveBytes is shorter that the expected message length (that should be checked). I have looked on the packets using Wireshark and they seems to be ok.

As mentioned in ros-industrial/fanuc#11, the JointTrajectoryInterface::stopMotionCB(..) service callback should return a success/failure indication based on the communication with the robot controller.

The current implementation always returns true -- as confirmation that the invocation of the ROS service call has succeeded.

What is the difference between JOINT_POSITION and JOINT_FEEDBACK which should be used and where?

As per subject.

IMHO it's confusing to have a master branch, as well as a hydro-devel. The latter is basically master. Removing master would also remove one redundant merge target for every commit against hydro-devel.

The header lists them in a different order than the respective ::load(..) and ::unload(..) methods use. This is rather confusing, as other headers list the fields in the same order as those methods.

The industrial deprecated package is meant to ease deprecation of packages within ROS and ROS-Industrial. It should be cleaned of anything that is officially unsupported (these are mostly arm-navigation support) and populated with any new deprecated items (none that I know of).

The split packet unit test fails every so often on the jenkins build farm:

http://jenkins.rosindustrial.org/job/ros_industrial_groovy_dev/37/
http://jenkins.rosindustrial.org/job/ros_industrial_groovy_dev/35/

Subsequent re-builds seem to correct the issue.

The failure seems to be related to a failure to initiate a socket (from the console output):

[ RUN      ] SocketSuite.splitPackets
�[31m[ERROR] [1384182287.055133928]: Failed to bind socket, rc: -1�[0m
/var/lib/jenkins/jobs/ros_industrial_groovy_dev/workspace/src/industrial_core/simple_message/test/utest.cpp:326: Failure
Value of: tcpServer.init(tcpPort)
  Actual: false
Expected: true
[  FAILED  ] SocketSuite.splitPackets (0 ms)

Invoking catkin_make --pkg industrial_robot_simulator install fails with:

error: supposed package directory 'industrial_robot_simulator' exists, but is not a directory
CMake Error at catkin_generated/safe_execute_install.cmake:4 (message):

  execute_process(/home/user/ros/industrial_trunk_catkin/build/industrial_core/industrial_robot_simulator/catkin_generated/python_distutils_install.sh)
  returned error code
Call Stack (most recent call first):
  cmake_install.cmake:36 (INCLUDE)


make: *** [install] Error 1

this->setConnected(false);

Can be found in tcp_socket.cpp:59 but is absent at udp_socket.cpp:58
I was having difficulty having my communication connect properly under UDP but it worked fine using TCP. Adding this line to the UdpSocket constructor fixed the issue. I'm guessing this is a bug.

For people that use this package to resample a trajectory uniformly and are using Cartesian paths, here are a few suggestions that can make this package better:

1. The sample_duration variable needs to be accessible so it can be modify from a C++ code; and
2. A tutorial/example would be great so users can implement the filter in their C++ code.

Would like to have a filter which simply smooths the results of OMPL style planners which tend to produce choppy plans near obstacles. A smoothing filter will simply replace each point with a weighted average of its surrounding waypoints/states. Code is written, just needs to be integrated, pulled requested and accepted.

Invoking catkin_make --pkg industrial_deprecated install fails.

Just something I thought of, but we could possibly detect endianness of the controller by sending it a ping (a simple_message ping). Checking the fields in the reply should make it clear as to what endianness the server is using. The ping would be send before all other traffic.

If not for automatic installation of byte-swapping handlers, this could be used to detect misconfiguration by the user (ie: he/she specified the wrong launch file parameter). A nicer error message could then be given to the user, instead of the current 'could not load array' or 'no handler registered for message type'.

This issue has been moved from: ros-industrial/ros_industrial_issues#2 (submitted by @clay-flannigan)

Native robot I/O should be supported through standard ROS-I interfaces. Most industrial controllers have built-in (embedded) I/O standard functions like fence-status, gripper-close, etc. They generally also support general purpose I/O. Exposing these I/O points would remove the requirement for separate networked I/O from the ROS PC.