-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document 'migrating' MoveIt cfg pkgs from abb_driver to abb_robot_driver #11
Comments
Perhaps good to note: the driver supports both joint position and joint velocity interfaces. Personally, I've noticed some minor vibration when executing trajectories using the With the EGM session configured for velocity control (ie: set Unfortunately, as that controller is no longer a pure forwarding controller, it requires gains, and those must be tuned. |
@dave992 FYI |
For a minimal working example, these are the steps I have taken:
|
I did not notice any vibrations when using the I however did notice that when using the
I could only execute another motion by manually updating the start state to the current state. Could this have anything to do with the egm setting? (Currently, I did not change any settings) |
if you're going to use MoveIt, I would probably just make sure the JTC gets started as part of the
"the EGM setting"? That error is from MoveIt, not the driver, so I'm not sure which EGM settings would influence this. |
Should have been plural ;). To clarify, I do not know if any of the EGM settings have an influence on how well the commanded trajectory is followed and when the robot controller considers the position reached. The error seems to indicate that the commanded end point is not reached, but does get used as the start point for the follow-up motion. |
it's not the robot controller. MoveIt prints this message. If you don't get a complaint from the Trajectory Execution Manager, then it's likely the trajectory was successfully executed (including the robot reaching its target destination within the requested tolerances). That would leave MoveIt not having planned from the latest state of the robot, but from some other state. |
@dave992 I met the same error showing that Invalid Trajectory: start point deviates from current robot state more than 0.01 and the problem may come from the PID tuning. I at first used your suggested value for the YuMI robot and found the arm was shaking after reaching the goal state. After changing the PID to {p: 1.0, d: 0, i: 0.00, i_clamp: 0.1} I could successfully finish consecutive movements |
Thanks for the suggestion, will try this when I pick this up again |
Every time i try to use the trajectory controller, I get the following error
weirdly enough, the group controller work. I am using the robotsudio simulation with the robot IRI1200 0.9 5, this is the part of the controller.yaml that includes the trajectory controller
I also added the type in the cmake and package files. |
The JTC inspects the URDF during load/init to get information on Is the
that controller does not do anything with URDFs, so it does not need the Edit: please clarify whether this is a problem related to updating/migrating MoveIt packages. If it isn't, please open a new issue instead of commenting here. |
Hi, I am facing similar issue while running abb_irb120_moveit_config (https://github.com/ros-industrial/abb_experimental) for my academic project - if @dave992 could add a tutorial for same or give more clarification on point 2 remapping and on other steps as well it ould be of great help. I want to run rapid files from robotstudio + moveit. Thanks |
this is insufficient information to help you. If you can provide details such as error or warning messages we might be able to provide guidance. |
<!--
Manipulator specific version of abb_driver's 'robot_interface.launch'.
Defaults provided for IRB 120:
- J23_coupled = false
Usage:
robot_interface_download_irb120.launch robot_ip:=<value>
-->
<launch>
<arg name="robot_ip" doc="IP of the controller" />
<arg name="J23_coupled" default="false" doc="If true, compensate for J2-J3 parallel linkage" />
<rosparam command="load" file="$(find abb_irb120_support)/config/joint_names_irb120_3_58.yaml" />
<include file="$(find abb_driver)/launch/robot_interface.launch">
<arg name="robot_ip" value="$(arg robot_ip)" />
<arg name="J23_coupled" value="$(arg J23_coupled)" />
</include>
</launch> replaced by code mentioned below although name of file is kept same (robot_interface_download_irb120_3_58.launch) <?xml version="1.0"?>
<launch>
<arg name="robot_ip" doc="The robot controller's IP address"/>
<!-- Enable DEBUG output for all ABB nodes -->
<arg name="J23_coupled" default="false"/>
<env if="$(arg J23_coupled)" name="ROSCONSOLE_CONFIG_FILE" value="$(find abb_robot_bringup_examples)/config/rosconsole.conf"/>
<!-- ============================================================================================================= -->
<!-- Robot Web Services (RWS) related components. -->
<!-- ============================================================================================================= -->
<!-- RWS state publisher (i.e. general states about the robot controller) -->
<include file="$(find abb_rws_state_publisher)/launch/rws_state_publisher.launch">
<arg name="robot_ip" value="$(arg robot_ip)"/>
</include>
<!-- RWS service provider (i.a. starting/stopping the robot controller's RAPID execution) -->
<include file="$(find abb_rws_service_provider)/launch/rws_service_provider.launch">
<arg name="robot_ip" value="$(arg robot_ip)"/>
</include>
<!-- ============================================================================================================= -->
<!-- Externally Guided Motion (EGM) related components. -->
<!-- -->
<!-- Notes: -->
<!-- * This example assumes that a 6-axes robot is used. -->
<!-- * An EGM session must be in running mode before starting 'ros_control' controllers that command motions. -->
<!-- ============================================================================================================= -->
<!-- EGM hardware interface (i.e. 'ros_control'-based interface for interacting with mechanical units) -->
<include file="$(find abb_egm_hardware_interface)/launch/egm_hardware_interface.launch">
<arg name="base_config_file" value="$(find abb_robot_bringup_examples)/config/ex2_hardware_base.yaml"/>
<arg name="egm_config_file" value="$(find abb_robot_bringup_examples)/config/ex2_hardware_egm.yaml"/>
</include>
<!-- Put 'ros_control' components in the "egm" namespace (to match the hardware interface) -->
<group ns="egm">
<!-- Load configurations for 'ros_control' controllers on the parameter server -->
<rosparam file="$(find abb_robot_bringup_examples)/config/ex2_controllers.yaml" command="load"/>
<!-- Two 'ros_control' controller spawners (stopped for the controller that command motions) -->
<node pkg="controller_manager" type="spawner" name="started" args="egm_state_controller joint_state_controller"/>
<node pkg="controller_manager" type="spawner" name="stopped" args="--stopped joint_group_velocity_controller"/>
</group>
</launch>
controller_list:
- name: ""
action_ns: joint_trajectory_action
type: FollowJointTrajectory
joints: [joint_1, joint_2, joint_3, joint_4, joint_5, joint_6] is replaced by controllers.yaml joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 250
egm_state_controller:
type : abb_egm_state_controller/EGMStateController
publish_rate : 250
# These settings must match:
# - Joint names extracted from the ABB robot controller.
joint_group_velocity_controller:
type: velocity_controllers/JointGroupVelocityController
joints:
- joint_1
- joint_2
- joint_3
- joint_4
- joint_5
- joint_6
joint_velocity_trajectory_controller:
type: velocity_controllers/JointTrajectoryController
joints: [joint_1, joint_2, joint_3, joint_4, joint_5, joint_6]
gains:
joint_1: {p: 100, i: 1, d: 1, i_clamp: 1}
joint_2: {p: 100, i: 1, d: 1, i_clamp: 1}
joint_3: {p: 100, i: 1, d: 1, i_clamp: 1}
joint_4: {p: 100, i: 1, d: 1, i_clamp: 1}
joint_5: {p: 100, i: 1, d: 1, i_clamp: 1}
joint_6: {p: 100, i: 1, d: 1, i_clamp: 1}
joint_position_trajectory_controller:
type: position_controllers/JointTrajectoryController
joints: [joint_1, joint_2, joint_3, joint_4, joint_5, joint_6]
# Simulation settings for using moveit_sim_controllers
moveit_sim_hw_interface:
joint_model_group: irb120_arm
joint_model_group_pose: drop
# Settings for ros_control_boilerplate control loop
generic_hw_control_loop:
loop_hz: 300
cycle_time_error_threshold: 0.01
# Settings for ros_control hardware interface
hardware_interface:
joints:
- joint_1
- joint_2
- joint_3
- joint_4
- joint_5
- joint_6
sim_control_mode: 1 # 0: position, 1: velocity
# Publish all joint states
# Creates the /joint_states topic necessary in ROS
joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 50
controller_list:
[]
- name: "/egm/joint_position_trajectory_controller"
action_ns: follow_joint_trajectory
type: FollowJointTrajectory
joints: [joint_1, joint_2, joint_3, joint_4, joint_5, joint_6] is the updated code. After this when I launched -
|
Please make use of the formatting options that Markdown has available, simply copy-pasting your terminal does not result in great readability as you might have also noticed (link). Please have a look at the following lines:
This to me looks like the driver cannot connect to the RWS service of the robot. As this is separate from migrating MoveIt configurations, I would recommend looking through the current issues tracker for comparable issues or start a new one if this is a problem that has not been reported earlier. Quick guess, remove the leading |
The RWS troubleshooting could be helpful to fix RWS communication issues. |
@dave992 Hi,I used the abb_robot_driver package to connect to RobotStudio, which I tested without problems. But I sent motion commands using the moveit package as you described above, and the robotic arm in RobotStudio didn't move. No errors were reported throughout the process.
|
@Levelsss Did you get the examples provided by the
RWS and EGM both provide a |
@dave992 yes,i get the examples provided by the Here is my complete
|
Was recently asked this by a colleague.
At a high-level the changes needed are:
moveit_planning_execution.launch
(or equivalent) to no longerinclude
therobot_interface_download_irb*.launch
from the robot support package, but something similar to (or perhaps even exactly like) abb_robot_bringup_examples/launch/ex2_rws_and_egm_6axis_robot.launch. This is responsible for loading theros_control
controller configuration onto the parameter server and starting the required nodes (main driver and RWS service node)name
and/oraction_ns
key in thecontrollers.yaml
file in the MoveIt configuration pkg (or equivalent file which configures thecontroller_list
parameter) to use the Action server topic of the new driver. In ROS-Industrial distributed MoveIt cfg pkgs, these are typically set to""
(forname
) andjoint_trajectory_action
foraction_ns
.ros_control
configuration from the bringup examples pkg in this repository, users would also need to add stanzas to add aJointTrajectoryController
to the configuration. MoveIt cannot talk to theJointGroupVelocityController
loaded by default.Of course, contrary to the old driver,
abb_robot_driver
needs some more management, so before trajectories can be executed, users will have to use the appropriate ROS services offered by the RWS service node to put the ABB controller in the right state (ie: make it run the required RAPID programs).The sequence of service invocations is shown in the readme of the
abb_robot_bringup_examples
package.The text was updated successfully, but these errors were encountered: