Closed skhbk closed 6 months ago
Thanks for reporting this. This package is still in a rather early stage (hence it is not released as binary form) and we currently don't have many resources available to work on this, I'm afraid.
Thanks for your response. Is this problem specific to my environment?
Thanks for reporting this. This package is still in a rather early stage (hence it is not released as binary form) and we currently don't have many resources available to work on this, I'm afraid.
Are this package and the Ignition sim package in a similar state?
Thanks for your response. Is this problem specific to my environment?
No, I'm seeing something similar on Rolling. The robot is actually undergoing slow relaxation oscillations in the relative joint poses in my case, but unfortunately my Gazebo video capture also isn't working :sweat_smile:
(Edit: the oscillations and breaking joints happen for me in the all-zeros starting posture if I turn on a little bit of x-direction gravity)
Thanks, @danzimmerman. I captured a video with all-zeros posture and some x-direction gravity.
I captured a video with all-zeros posture and some x-direction gravity.
Yes, very similar to what I'm seeing. If I figure anything out about workarounds/fixes, I'll post here and/or make a PR.
Yes, very similar to what I'm seeing. If I figure anything out about workarounds/fixes, I'll post here and/or make a PR.
I'm experiencing the same issue on humble (galactic was fine). Feel free to document your process, maybe we can figure it out together!
galactic was fine
That's interesting.
Will definitely document what I find if I find anything. I just got back to working on this.
Can confirm it works fine on Galactic. (Ubuntu 20.04 native install)
These issues seem similar, several different suggestions there.
https://github.com/ros-controls/gazebo_ros2_control/issues/73 https://github.com/ros-controls/gazebo_ros2_control/issues/54
@relffok Among other discussion of the Gazebo fmax
parameter, I found this comment from a while back (I added the bold emphasis):
_@JaehyunShim Here is my comments https://github.com/ros-controls/gazebo_ros2_control/pull/44#discussion_r565177746. There are several ways to workaround it. Currently, I created an additional gazebo plugin to help calling SetParam("fmax", 0,
) inside the Load() function , so that when joint_limit_interface is ready, I can simply remove my own plugin. You can also modify the gazebo_ros2control to add in your own fix.
It seems like there's something similar in gazebo_ros_control
for Noetic here where the joint's fmax
is set to the joint's effort limit:
{
// joint->SetParam("fmax") must be called if joint->SetAngle() or joint->SetParam("vel") are
// going to be called. joint->SetParam("fmax") must *not* be called if joint->SetForce() is
// going to be called.
#if GAZEBO_MAJOR_VERSION > 2
joint->SetParam("fmax", 0, joint_effort_limits_[j]);
#else
joint->SetMaxForce(0, joint_effort_limits_[j]);
#endif
}
I forked and modified gazebo_ros2_control
implementation of GazeboSystem::registerJoints(...)
here and set a random large limit:
// At first we do a test with an arbitrary force limit of 1e6
this->dataPtr->sim_joints_[j]->SetParam("fmax", 0, 1000000.0);
To get the robot to move, I'm using
ros2 launch ur_robot_driver test_joint_trajectory_controller.launch.py
On the as-is humble
branch of gazebo_ros2_control
, the robot is badly broken:
On my dz/humble-fmax-test
branch, the robot seems to work fine:
According to this comment, this comment and the Noetic code in ROS 1 gazebo_ros_control
above, this is something that should be handled with the joint limits interface.
So I need to look into ros2_control/joint_limits_interface to see what's going on there.
I don't think I have access to joint limit data where I hacked it in to gazebo_ros2_control
.
Also worth noting is this joint friction/damping plus use_sim_time
workaround suggested by @shonigmann here, however my galactic
installation has a mix of use_sim_time
settings on the nodes, as far as I can tell has zero damping or friction specified in the joints (retrieved with gz model --model-name ur --info
) and that works fine.
Another observation:
When I set fmax
from the code, the joints' friction
parameters change to the value I set.
In gazebo_ros2_control/src/gazebo_system.cpp
:
this->dataPtr->sim_joints_[j]->SetParam("fmax", 0, 867530.9);
In the description retrieved with gz model --model-name ur --info
:
joint {
name: "ur::shoulder_pan_joint"
id: 47
angle: 0.0059931542239271
type: REVOLUTE
parent: "ur::base_link"
parent_id: 11
child: "ur::shoulder_link"
child_id: 16
pose {
position {
x: 0
y: 0
z: 0
}
orientation {
x: 0
y: 0
z: 0
w: 1
}
}
axis1 {
xyz {
x: 0
y: 0
z: 1
}
limit_lower: -6.28319
limit_upper: 6.28319
limit_effort: 150
limit_velocity: 3.14159
damping: 0
friction: 867530.9 <---------- Set from code by setting fmax
use_parent_model_frame: false
xyz_expressed_in: ""
}
}
There's a Gazebo Answers post suggesting they need to be set together:
There's an archived Bitbucket PR for Gazebo discussing this a bit:
https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-requests/1221/page/1
Another Gazebo Answers post about fmax
and friction:
https://answers.gazebosim.org/question/24487/change-joint-characteristics-at-runtime/
To lock a joint, I would set the
fmax
field to a large value andvel
to 0 (this is also how we set joint friction, using both fmax and vel)
The dParamFMax
parameter is set here in ODEJoint::SetParam(...)
(and at Line 444 for friction, which as the post says uses vel
and fmax
).
It also appears that a max_force
tag in the SDF would pass through to the fmax
parameter here at Line 131.
max_force
/fmax
seem to be the maximum force for an ODE joint motor as described here:
http://ode.org/wiki/index.php/Manual#Stops_and_motor_parameters
Joint motors solve all these problems: they bring the body up to speed in one time step, provided that does not take more force than is allowed. Joint motors need no extra parameters because they are actually implemented as constraints. They can effectively see one time step into the future to work out the correct force.
In prior implementations it seems like people have been setting fmax
to the joint effort limit but given the description above I'm not sure that's right. The effort limit is a separate parameter anyway:
limit_lower: -6.28319
limit_upper: 6.28319
limit_effort: 150 <--- effort limit from URDF xacro
limit_velocity: 3.14159
damping: 0
friction: 867530.9 <--- fmax set in code
Some more docs on joint motors:
https://classic.gazebosim.org/tutorials?tut=set_velocity&cat=#SetJointVelocityUsingJointMotors
The first call sets the key vel to the velocity the joint should travel at. It is meters per second for prismatic joints and radians per second for all others. The other call sets the key
fmax
. It is the maximum force or torque a joint motor may apply during a time step. Set it larger than the force required to be at the target velocity at the next time step. Set it smaller to apply a force over many time steps until the velocity is reached.
In velocity/position control, I'd think we'd always want to stay well over the minimal amount of joint torque to achieve the next joint velocity in simulation.
I'd think the effort limits from this page should probably be handled some other supervisory way (joint_limits_interface
?) if they're included at all in Gazebo simulation. The real UR robot will not start slowly accumulating velocity errors if you exceed its joint limits, it'll just fault.
I'm going to see if I can pass max_force
through from the .urdf.xacro
file instead of injecting it in the source code.
I'm going to see if I can pass
max_force
through from the.urdf.xacro
file instead of injecting it in the source code.
I didn't get that to work yet. The draft PR mentioned above uses the joints' <dynamics>
tags to add "friction" instead, which ultimately sets dParamFMax
, but this is specific to ODE and a little confusing.
It's potentially a good interim workaround to this issue if you're planning to use Open Dynamics Engine. It's simple.
Excellent documentation, thanks so much! I haven't had the time to look into the reasons for the parameter adaptions, but I quickly tested the mentioned PR and I can confirm it works on debian humble (UR_gazebo and UR_descr from source) as I used ODE as well.
I also quickly used MoveIt to control the adapted robot, which I can confirm to work as well (with adaptions of https://github.com/UniversalRobots/Universal_Robots_ROS2_Gazebo_Simulation/pull/22) I will have a closer look at your findings as soon as I find the time!
@danzimmerman your solution was very helpful. thanks !!!
@Wiktor-99 worked with our own manipulator in gazebo simulation on ROS 2 Foxy and he found out solution for moving joints.
It is necessary to add dynamics
tag with damping
and friction
and implicitSpringDamper
for the joints with the gazebo reference.
<joint name="${prefix}wrist_3_joint" type="revolute">
[...]
<dynamics damping="0.7" friction="1.0"/>
</joint>
<gazebo reference="${prefix}wrist_3_joint">
<implicitSpringDamper>true</implicitSpringDamper>
</gazebo>
I applied this to the ur_description
and the joints don't break anymore.
It is necessary to add
dynamics
tag withdamping
andfriction
andimplicitSpringDamper
for the joints with the gazebo reference.
In my tests, setting friction
is enough. Wonder if that works for you?
@danzimmerman I will check that!
Hi! I tested only friction parameter in dynamics tag:
<dynamics friction="1.0"/>
Here are the videos: Screencast from 18.05.2023 14:25:40.webm Screencast from 18.05.2023 14:21:30.webm
Screencast from 18.05.2023 14:21:04.webm
The best solution is to add this 3 configurations for joints:
<joint name="${prefix}wrist_3_joint" type="revolute">
[...]
<dynamics damping="0.7" friction="1.0"/>
</joint>
<gazebo reference="${prefix}wrist_3_joint">
<implicitSpringDamper>true</implicitSpringDamper>
</gazebo>
Hi! I tested only friction parameter in dynamics tag:
<dynamics friction="1.0"/>
I can confirm this result when friction
is set to 1.0 for each joint in the UR3e.
However, if I set the friction higher, here, to 1.0x the joint's effort limit, the model is stable with no damping. For example, these settings are stable:
From my fork:
That setting, friction set to 1.0x the joint effort limit, should be equivalent to the ROS 1 behavior.
Will try to figure out where damping
goes into ODE and whether either of these approaches alters reported joint efforts while the robot is moving (though it looks like I'm getting all-zero efforts on /joint_states
at the moment)
Hi, how are you opening this robot in Gazebo, can you please provide the exact command?
Hi @Gaurang-1402,
the exact command I used was:
ros2 launch ur_simulation_gazebo ur_sim_control.launch.py ur_type:=ur10
This launches a ur10. If you want a different robot you can change it after the "=". You can find selectable options in the ur_sim_control.launch.py-file.
@fmauch Based on a quick test here, it looks like https://github.com/ros-controls/gazebo_ros2_control/pull/213 fixed this issue.
Hi, @danzimmerman,
It did not work for me when I am using ros2
branch of Universal_Robots_ROS2_Gazebo_Simulation
with latest version of gazebo_ros2_control
in ROS Humble.
Still need modifications of dynamics or friction ?
Thanks in advance!
Things seem to be fine by now, so closing this.
My Environment
Description
When I start simulation by using![default_gzclient_camera(1)-2022-11-18T18_07_23 988005](https://user-images.githubusercontent.com/84374700/202672289-69fbc77a-a762-48cd-a521-27d0ecad2fb9.jpg)
ros2 launch ur_simulation_gazebo ur_sim_control.launch.py
, the robot's joints break as in this image:To clarify this phenomenon, I changed the initial joint positions as follows:
If the controller is not activated, this does not happen (the robot just lies down).
My Attempts
Turning off gravity
I added
turnGravityOff
tag for each link in the URDF description:Then the robot looks fine, but it may behave the same for external forces other than gravity.
Increasing damping and friction
Increasing the values of damping and friction for each joint in URDF made the robot stable, but the joints still shift a little.
Adding CFM and ERP
I didn't see the effect of this.