Adding cartesian_force_controller to controller_manager in ros2 #61
Comments
cschempp
changed the title
|
Hi @cschempp The port to ROS2 is currently under development. Please use the ros2-devel branch for the meantime.
Yes, the controller's type changed to controller_manager:
ros__parameters:
...
cartesian_force_controller:
type: cartesian_force_controller/CartesianForceController
... Also note that the controller gains might need some smaller adaptation to ROS2. This is currently experimental. Anything you can share about your experience on your system (+ use case an good controller parameters) is greatly appreciated! |
|
Hi @stefanscherzinger , thank you for the quick reply. Ok, i will use the ros2-devel branch. |
|
Hi, I am also using a UR5e robot for force control. I followed @cschempp 's steps to run the controller along with @stefanscherzinger 's suggestions. I ran the launch command
|
|
Hi @TheFalcoGuy
Fortunately, that one got ported recently. Please contribute new features of your port with a PR :) Concerning the error messages:
Comes from the controllers' base class if we don't specify the parameter cartesian_compliance_controller:
ros__parameters:
end_effector_link: "tool0"
robot_base_link: "base_link"
ft_sensor_ref_link: "tool0"
compliance_ref_link: "tool0"
joints:
- joint1
- joint2
- joint3
- joint4
- joint5
- joint6
# Choose: position or velocity.
command_interfaces:
- position
#- velocity
stiffness:
trans_x: 11.0
trans_y: 22.0
trans_z: 33.0
rot_x: 44.0
rot_y: 55.0
rot_z: 66.0
pd_gains:
trans_x: {p: 0.05}
trans_y: {p: 0.05}
trans_z: {p: 0.05}
rot_x: {p: 0.01}
rot_y: {p: 0.01}
rot_z: {p: 0.01}
You can take a look at the |
stefanscherzinger
added
the
solution proposed
|
Thanks for porting the compliance controller. I decided to use your controller over mine since it would be more consistent with the codebase. I cloned the latest commit, followed your solution and got the following error message when trying to load the cartesian_force_controller: I suspect this is a result of the commit you made to the base class as I was able to load the force controller using the previous commit. I also tried using your version of the compliance controller. An error happens when I try building the compliance controller on line 83 of cartesian_compliance_controller.cpp: After making that change, I get the same error as the cartesian force controller. I was wondering if you can give some advice on 1) how to debug the cartesian_force_controller error with the latest commit and 2) whether the cartesian_compliance_controller bug fix is correct? Thanks. |
Thanks, that pointed me to something important. The I'll try to support Concerning your point 1): I'll personally like using gdb inside a screen session. Note the line with the control_node = Node(
package="controller_manager",
executable="ros2_control_node",
parameters=[robot_description, robot_controllers],
#prefix="screen -d -m gdb -command=/home/scherzin/.ros/my_debug_log --ex run --args",
output={
"stdout": "screen",
"stderr": "screen",
},
)After picking up the gdb session with |
|
I updated the ros2-devel branch with the latest fixes for the Foxy support. You might want to check that out and try again. |
|
Thanks for being so quick. I tried running the compliance controller with my ur5e. I noticed that I am facing a similar issue in #15 where the cartesian compliance controller is getting information from the incorrect topic. Unlike ROS1, however, parameter remapping from the launch file is slightly trickier as there is no global parameter anymore. I tried remapping by directly changing line 101 in cartesian force controller. After doing that and running the setup as before, I got motion, though I am not entirely sure if this is expected behavior. Below is my yaml file and a video recording of the controller: My yaml file is as follows: My goal is to use the compliance controller as an admittance controller. How would I go about tuning this to get that behavior? Thanks |
At runtime, ROS2 controllers are part of the control_node = Node(
package="controller_manager",
executable="ros2_control_node",
parameters=[robot_description, robot_controllers],
#prefix="screen -d -m gdb -command=/home/scherzin/.ros/my_debug_log --ex run --args",
output={
"stdout": "screen",
"stderr": "screen",
},
remappings=[
('m_ft_sensor_wrench', 'the_measured_ur_sensor_wrench'),
]
)remaps the
Thanks for sharing the video! That's not expected behavior. For some axes, the robot moves towards the directions where forces are applied. I assume that this is because the cartesian_compliance_controller:
ros__parameters:
end_effector_link: "tool0"
robot_base_link: "base_link"
ft_sensor_ref_link: "tool0"
compliance_ref_link: "tool0" # This one is important
...You might also remove the following parameters form the state_interfaces:
- position
- velocity
state_publish_rate: 100.0
action_monitor_rate: 20.0
allow_partial_joints_goal: false
constraints:
stopped_velocity_tolerance: 0.0
goal_time: 0.0`Those parameters won't be used. I don't know where you got them from. I also noticed that your controller is very responsive. That won't be stable in contact with stiff surfaces. Keep in mind that you might need to tweak the controller's cartesian_compliance_controller:
ros__parameters:
...
solver:
error_scale: 0.1
Could you be more specific what you mean by that? |
|
Hi @stefanscherzinger, sorry for the late reply. I took your advice and have started tuning my controller. After adding the compliace reference link, the issue you pointed out still remains. When I inverted the proportional gains, however, the robot behaves as expected. The error scaling you mentioned helped adjusting the controller's sensitivity. During the tuning process, I noticed that applying a large amount of force on the arm results in the arm drifiting in the direction of where the force was applied. I tried adding a k_i term as I thought this was a result of some steady state error, but it didn't seem to help the situation. I was wondering if you had any experience with dealing with this issue? Thanks again for the advice! |
You mean like cartesian_compliance_controller:
ros__parameters:
end_effector_link: "tool0"
robot_base_link: "base" # The force sensor reference frame for the UR driver in Foxy
ft_sensor_ref_link: "tool0"
compliance_ref_link: "tool0"
...I remember that the UR driver used
That's not required. The control law has an integrator already when integrating the simulated accelerations to velocities and positions.
After fixing the kinematics config from above, is that still the case? |
|
ubuntu 20.04 | fzi cart_force_controller on branch foxy | universal robots ros2 driver on branch foxy | For continued development and work in foxy, (using the force and compliance controllers) which branch(es) do you suggest? |
|
Hi @lcbw Sorry, I didn't check your post after your edit and missed your question. I suggest using the |
Hello, I'm following this response to setup the cartesian force controller on a UR10e on ros2 and am a bit confused with the terminology. What is the significance of the "stopped" in Aditionally, I followed the steps mentioned in the comment, but I am also wondering whether the |
Hello,
i tried adding the cartesian_force_controller from the ros2 branch into the ur_control.launch.py of the UR ROS2 Driver package.
Therefore i cloned this repo and build the packages cartesian_controller_base and cartesian_force_controller in my workspace.
I then added
to the launch_setup in ur_control.launch.py and
cartesian_force_controller_spawner_stoppedin the nodes_to_start = [ .... ].In the ur_controllers.yaml where the controllers are defined, i added
and under controller_manager: ros__parameters: i added the line
If i list the controller types with
ros2 control list_controller_types, the cartesian_force_controller/CartesianForceController is there.But loading the controller with
ros2 control load_controller cartesian_force_controlleryields the error message:Error loading controller, check controller_manager logs. The logs say "Loader for controller 'cartesian_force_controller' not found".
What is the correct way to register a new controller to the controller_manager started in an existing .launch file?
Any help would be really appreciated.
The text was updated successfully, but these errors were encountered: