As noted in #19: TCP time-outs take a minimum of around 1 minute on the Fanuc controller. Using a condition handler to catch program exit (or ABORT) and then closing open sockets explicitly should speed things up.

See #12.

The ros_relay KAREL program uses a number of integer and position registers to communicate with the ros_movesm TPE program. These are currently hard-coded. This presents problems on controllers where those registers are already used in other (TPE) programs.

Fix: add support for runtime configurable register indices.

Migrated from swri-ros-pkg Google Code issue list: http://code.google.com/p/swri-ros-pkg/issues/detail?id=31

As per subject. Example are the math 'libraries': Karel already defines constants like PI and DEG2RAD, which would make ours redundant.

• math constants / functions
• [ ] error levels
• ascii colour codes
• IO definitions (SOP, UOP, etc)

When running in Roboguide, it seems the CE/CR Select bits are not set. This results in ros_state to always report the controller to be in manual mode, regardless of its actual state.

Current implementation accepts only JOINT_TRAJ_PT messages. JOINT_TRAJ_PT_FULL contain more information (position, velocity and acceleration).

Using JOINT_TRAJ_PT_FULL would also help #6: ros_relay only controls first motion group.

As per subject: the list of package dependencies is incomplete in the ported arm navigation packages.

Seems the KAREL runtime performs some sort of lazy loading: missing dependencies of a program only result in errors (INTP-368: (PROG, LINE) Cannot use specified program) if any symbols within those dependencies are actually used in execution paths.

Add a check at startup to make sure that all required KAREL programs are loaded on the controller and error-out early.

LOAD_STATUS(..) can be used for this.

As per subject.

As per subject: some (all?) support packages contain xacros that use the shorthand <include filename=.. /> instead of the proper <xacro:include ../>.

This should be fixed.

Similar to #49: determine the actual effort limits for every joint. This information might be stored in the files on the controller.

• M-10iA
• M-16iB/20
• M-20iA
• M-20iA/10L
• M-430iA/2F
• M-430iA/2P
• LR Mate 200iC
• LR Mate 200iC/5H
• LR Mate 200iD

As per subject.

Currently blocked as the catkin version of the macro is only available for roslaunch >= 1.9.48 and that has not been released yet.

Currently, ros_state and ros_relay need to be recompiled in case the user wants to change the used server TAGs. This is inconvenient (and involved).

These should be configurable using only the TP on the controller.

As per subject line.

metapackage <run_depends> on fanuc_m430ia_arm_navigation which doesn't exist.

As per the title: make ros_state also report joint velocities, in addition to joint positions as it currently does.

If possible acceleration should be included as well.

ros_state would first need support for JOINT_FEEDBACK simple_message messages. Exploiting the valid fields field allows for incremental implementation of this issue.

Blocked by: #5.

As per subject.

See #12.

See #12.

As mandated by the Industrial Robot Driver Specification, section 1.3.3, under Services:

• stop_motion (industrial_msgs/StopMotion)
  • stop current robot motion
  • can resume motion by sending a new motion command

See ros-industrial/ros_industrial_issues#8.

fanuc_driver already sort of implements this, but needs to be done properly.

Subtasks:

• report state of all motion groups with ros_state (was: #4)
• add support for JOINT_FEEDBACK messages to ros_state (was: #5)
• ros_relay only controls first motion group (was: #6)
• add support for JOINT_TRAJ_PT_FULL message to ros_relay (was: #7)

They should include the launchfile provided by industrial_robot_simulator.

Many of the Fanuc manipulators support different configurations: dress-outs, mounting angles, etc. While the support packages currently do specify the documentation (and version) that provided the joint limits, information on the specific configuration used to generate the URDF is missing.

This should be added.

• M-10iA
• M-16iB/20
• M-20iA
• M-20iA/10L
• M-430iA/2F
• M-430iA/2P
• LR Mate 200iC
• LR Mate 200iC/5H
• LR Mate 200iD

See #12.

See ros-industrial/ros_industrial_issues#6.

The Industrial_Robot_Driver_Spec/HardwareCompatibility is outdated with respect to what the fanuc_driver does and does not support.

It should be updated.

See #12.

Currently shows something like:

26139 I RSTA Waiting for ROS state prox

The first integer is like MM:SS, but unrecognisable as such. It is currently only meant to offer some indication of which lines are chronologically 'close'.

This should either be removed, or reworked to show something intelligible.

The Industrial/supported_hardware is outdated with respect to the current status of the fanuc_driver.

It should be updated.

See #12.

As mandated by the Industrial Robot Driver Specification, section 1.3.4, under Kinematics:

To enable real-time motion planning and collision avoidance, the node should provide robot-specific inverse kinematics solutions. A generic solver is provided in ROS, but it operates too slowly for collision-avoidance path planning. As described here and here, the ikfast tool can be used to generate the required kinematics files for any 6-DOF serial manipulator. These files should be integrated with ROS as a plugin, not a service, to avoid expensive communications-related overhead. This involves creating a launch file to connect your plugin with the ROS arm_kinematics_constraint_aware node, as described here.

This is a composite issue:

• #13, M-10iA
• #14, M-16iB/20
• #52, M-20iA
• #53, M-20iA/10L
• #15, M-430iA/2F
• #16, M-430iA/2P
• #34, LR Mate 200iC
• #35, LR Mate 200iC/5H

Make sure the fanuc_driver functions as described in ros-industrial/ros_industrial_issues#4: return errors for unknown packet types.

The fanuc wiki main page ( http://wiki.ros.org/fanuc ), shows the software status for the groovy version. "Groovy" is "hard coded" into the wiki. The desired method of doing this is to use the wiki version macros as shown here: http://wiki.ros.org/Industrial/Software_Status#Full_Example.

In the future, we hope that the software status will be embedded in the auto-generated content at the top of each page. This content is tied to ROS versions. By following the example above the page layout will not change if/when this information becomes embedded in the auto-generated content.

JOINT_FEEDBACK messages provide more information on the state of the manipulator (position, velocity and acceleration vs only position).

This would also help with #4: reporting state on all motion groups in the robot.

It's the only one with an IKFast plugin, which would need to be ported.

Perhaps look at work in ABB repository.

Acceleration limits currently specified in the Arm Navigation and MoveIt configuration packages are calculated values, not actual limits.

Todo: determine actual acceleration limits and update MoveIt configuration packages.

• M-10iA
• M-16iB/20
• M-20iA
• M-20iA/10L
• M-430iA/2F
• M-430iA/2P
• LR Mate 200iC
• LR Mate 200iC/5H
• LR Mate 200iD

The value of the J23_factor can be determined at runtime using info that is stored on the controller on which the KAREL programs are running. As this is (at the moment) the only difference between the fanuc_driver and the generic industrial_robot_client binaries, this would allow the fanuc_driver to return to using those generic binaries.

This would reduce the amount of custom code and launch files, thus reducing maintainance effort and potential sources of errors.

The github description should be updated to the following: ROS-Industrial fanuc meta-package. http://ros.org/wiki/fanuc. This results in the wiki link being shown on the ROS-Industrial github org's main page. This combined with the repo readme should remove any misunderstanding about where the packages are documented.

As mandated by the Industrial Robot Driver Specification, section 1.3.3, under Services:

• joint_path_command (industrial_msgs/CmdJointTrajectory)
  • execute a new motion trajectory on the robot
  • identical functionality to the joint_path_command topic
  • the service-implementation allows calling code to receive confirmation that a commanded trajectory has actually been received by a robot node.

Seems to have been missed when the stack was reorganised.

Arm navigation package of the M-430iA/2F still contains references to old package name in some launch files.

Minimum timeout value for server TAGs on the controller is 1 minute. This value seems to be used to configure the TCP timeout on open sockets. Only after this time the controller will report an error to the program making use of the TAG (connection).

Perhaps a heartbeat system should be implemented -- as suggested by the Industrial Robot Driver Specification, section 1.2.2, under Communications. This would allow for much shorter timeout values, increasing responsiveness of the driver.

As per the title: the ros_relay KAREL program currently sets a fixed joint speed (hard-coded to 20%) instead of using the commanded speed.

Migrated from swri-ros-pkg Google Code issue list: http://code.google.com/p/swri-ros-pkg/issues/detail?id=32

See #12.

The fanuc_driver package contains directories with upper case names.

The current implementation of ros_state only reports the state of the first motion group of the robot. Any additional axes will not be included in the state report. This makes it impossible to control positioners or any other non-arm axes controlled by the robot controller.

As mandated by the Industrial Robot Driver Specification, section 1.2.2, under Communications:

• both sides of the robot-ROS connection should handle communications-loss scenarios:
  • [...]
  • the robot shall
    • stop motion and power off the drives
    • [...]

The current implementation (if run in auto mode) does not power down the servos. This should be fixed.

It is unclear whether this is possible: the OS on the robot has control over servo power, and determines whether it should keep them powered, or not.

The ros_relay KAREL program only controls the first motion group. Any additional axes are ignored. This makes it impossible to control any positioners or external axes for instance.

This makes it impossible to release those packages, as catkin packages cannot depend on rosbuild packages.

planning_environment is one such package: it is (still) dry and the arm navigation packages of the M-10 and the M-430 depend on it.

Some of the meshes in the visual subdirectories have currently a rather high face and vertex count, which can result in a large visualisation overhead when displaying the model in RViz.

Suggestion: decimate quality of those meshes, but keep them detailed enough.

This would also lower total filesizes of those meshes.

See #12.