ros-industrial / fanuc Goto Github PK
View Code? Open in Web Editor NEWROS-Industrial Fanuc support (http://wiki.ros.org/fanuc)
License: Other
ROS-Industrial Fanuc support (http://wiki.ros.org/fanuc)
License: Other
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.
See #12.
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.
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.
As per subject.
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.
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.
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.
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.
See #12.
See #12.
See ros-industrial/ros_industrial_issues#8.
fanuc_driver
already sort of implements this, but needs to be done properly.
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.
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.
The Industrial_Robot_Driver_Spec/HardwareCompatibility is outdated with respect to what the fanuc_driver
does and does not support.
It should be updated.
The fanuc_driver
package contains directories with upper case names.
See #12.
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.
It's the only one with an IKFast plugin, which would need to be ported.
Perhaps look at work in ABB repository.
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.
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.
They should include the launchfile provided by industrial_robot_simulator
.
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.
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.
Similar to #49: determine the actual effort limits for every joint. This information might be stored in the files on the controller.
See #12.
See #12.
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.
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
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.
See #12.
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.
The Industrial/supported_hardware is outdated with respect to the current status of the fanuc_driver
.
It should be updated.
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.
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 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
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.
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.
Make sure the fanuc_driver
functions as described in ros-industrial/ros_industrial_issues#4: return errors for unknown packet types.
As per subject line.
metapackage <run_depends>
on fanuc_m430ia_arm_navigation
which doesn't exist.
As per subject. Example are the math 'libraries': Karel already defines constants like PI
and DEG2RAD
, which would make ours redundant.
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.
As per subject.
As per subject: the list of package dependencies is incomplete in the ported arm navigation packages.
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.
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.