ros-industrial / motoman Goto Github PK
View Code? Open in Web Editor NEWROS-Industrial Motoman support (http://wiki.ros.org/motoman)
ROS-Industrial Motoman support (http://wiki.ros.org/motoman)
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.
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.
The second release, an Indigo release (~3 months), will only support v1.2 controller side software.
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
Would remove the need to build packages from source.
sia5d_support
xacro macro (refers to files in motoman_config
)has been deprecated for quite some time now already.
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.
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)
?
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
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.
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"/>
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.
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.
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
Request tool0 be added to each robot, and URDFs updated.
Blocking on PR #42, #43 and ros-industrial/industrial_core#82.
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.
Provide group information for every debugging message. E.g. JointFeedbackRelayHandler::convert_message(.., int robot_id)
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/ ).
As per the subject: package.xml
is missing a buildtool depend on catkin
.
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.
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.
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
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
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.
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.
Same as #32.
Also for ros-industrial/ros_industrial_issues#23.
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.
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.
The CMakeLists.txt
of the dx100
and fs100
packages are missing install targets. This makes it impossible to use them in a install space.
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.
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:
motoman_driver
based on the code in #89.
[/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.
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.
Check the feasibility of changing back the joint names for the SDA10F and SIA10F from motoman_joint_N_L to motoman_joint_L
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'
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.
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).
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
.
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).
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!
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.
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
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).
As discussed in ros-industrial/ros_industrial_issues#24.
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.
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.