ros-industrial / abb Goto Github PK
View Code? Open in Web Editor NEWROS-Industrial ABB support (http://wiki.ros.org/abb)
ROS-Industrial ABB support (http://wiki.ros.org/abb)
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);
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).
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
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
As per subject.
Starting with Hydro, this will result in warnings of deprecation being printed.
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.
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).
Issue #42 is a true bug. It should be back ported to the hydro release.
@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.
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.
Split of from ros-industrial/abb_experimental#21.
Current suggestion:
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
.
See also ros-industrial/motoman#57 and ros-industrial/fanuc#142.
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.
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.
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 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.
Overwritten with default file generated by the MoveIt Setup Assistant (in 0529203). moveit_planning_execution.launch
now doesn't work correctly.
roscpp
and moveit_core
are listed as both DEPENDS
and CATKIN_DEPENDS
. They are actually catkin packages, and should only be under CATKIN_DEPENDS
.
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.
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).
From abb_driver
s 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?.
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
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?
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.
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.
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
As discussed in ros-industrial/ros_industrial_issues#24.
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}}}}}"
[0, 0, 0, 0, 0, 0]
[0, 0.15, -0.28, 0.0, 1.70, 0.0]
Other ABB models are not affected, because no IKFast plugin has been created.
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.
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.
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].
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.
As per subject.
Many manifests list the email address of @shaun-edwards as sedewards@..
.
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!
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:
/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.
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.
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
See detailed write-up on google code here.
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.
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.
The irb2400 plugin was generated some time ago. It should be regenerated to take advantage of new changes and updates.
See #36
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.