Open crvogt opened 2 years ago
Commands corresponding to each joint do not reflect what is echoed in the ft_sensor_(joint)
topic. Ie, the commands don't seem to be causing the issues as they appear relatively smooth coming from joint_position_controller.py
.
I thought it could be a sampling issue with rqt_plot, but echoing rexrov/tf_sensor_(joint)/wrench/torque/*
does, as expected, show the observed oscillations.
Currently, I do not think this is a controller tuning issue. Leading theories are:
I changed the joint limits and home pose for the Oberon7 based on detected collisions in the MoveIt setup assistant.No changes to behavior were observed.
Inertia values were also changed a la https://answers.gazebosim.org//question/18895/the-data-are-noisy-when-using-libgazebo_ros_ft_sensorso/ . Values were increased and decreased by an order of magnitude in an attempt to evoke a visibile response, but there were no obvious differences.
I think I'm able to reproduce it. It only happens when the joystick is attached and used, right?
May be related to an existing upstream issue https://github.com/osrf/gazebo/issues/2477 Looks like they've tried the inertia tweak and didn't see an effect. They've also considered whether it's noise. They're using velocity control. They’ve also tried removing the joint controller.
Additional comments link to these posts https://answers.gazebosim.org//question/19323/gazebo-70-recommended-way-to-get-torque-applied-to-a-joint-by-the-environment-joint-effort-feedback-via-gazebo-api/ https://answers.gazebosim.org//question/1523/drcsim-simulated-force-measurements-in-wrong-coordinates/#1952
One difference is that uuv_manipulators/oberon7/oberon7_control/launch/joint_effort_controllers.launch
is already using effort control, which is the recommended way for physics to respond smoothly (as opposed to velocity or position control).
If it's an upstream issue, I don't know how easy it is to fix. It might be that it hasn't been fixed because it's difficult, or because no one internally has needed it. In the latter case, this can be a good enough reason to fix it.
How important are the spikes? Are you relying on them for feedback control?
Further testing with ros industrial and even the simple rrbot example are showing the same issues with the ft_sensor plugin.
RRBot with plotted joint torques |
---|
![]() |
Unless we're putting a PR in to ROS or Gazebo, I'm going to close this for the time being.
I opened the gazebo_ros_ft_sensor_demo.world from gazebo_plugins
, and I was able to observe significant noise in the force-torque measurement of that double pendulum. My first thought is that this is connected to issues with convergence in the ODE constraint solver, since the default "quick" solver uses an iterative Projected Gauss-Seidel algorithm. I tried switching to the world
solver and saw much less noise in the force-torque sensor data. Note that the world
solver uses a pivoting algorithm and is generally more accurate, but has poor behavior when the constraint solver does not find a good solution, which is why it is not the default.
Since that demo world is strictly a passive model with no feedback control, I suspect it is not related to https://github.com/osrf/gazebo/issues/2477, but it does raise the point that it's important for the physics to be properly tuned. I will test further with the dave_manipulator_spring
launch files
I've recorded screen captures of gazebo_ros_ft_sensor_demo.world showing the reduction in force-torque noise when using the world
solver in https://github.com/ros-simulation/gazebo_ros_pkgs/pull/1354
I will try using this solver parameter with the underwater manipulator world to see if it improves that scenario as well.
One thing to watch out for with the world-step solver is an excessive number of console error messages that include the phrase LCP internal error
. We added an ode_quiet
parameter in Bitbucket pull request 2512 https://github.com/osrf/gazebo/commit/dacd9151a198562061ce013d0a70776f821a6ea7 that is typically set with an API call from a plugin:
I just loaded this again, and I noticed some console errors during roslaunch
that I didn't have all the run-time dependencies installed, and it was complaining that some effort controllers could not be loaded. I resolved that with rosdep install -i -y --rosdistro noetic --from-paths src
in my workspace. Now I'm not seeing the noise issues that you were mentioning.
I've also tried using the world-step solver, and it seems to work as well:
diff --git a/models/dave_worlds/worlds/dave_ocean_waves.world b/models/dave_worlds/worlds/dave_ocean_waves.world
index ec56db4..c2ebcb3 100644
--- a/models/dave_worlds/worlds/dave_ocean_waves.world
+++ b/models/dave_worlds/worlds/dave_ocean_waves.world
@@ -22,6 +22,11 @@
<max_step_size>0.002</max_step_size>
<real_time_factor>1</real_time_factor>
<real_time_update_rate>500</real_time_update_rate>
+ <ode>
+ <solver>
+ <type>world</type>
+ </solver>
+ </ode>
</physics>
<scene>
<ambient>0.01 0.01 0.01 1.0</ambient>
I just loaded this again, and I noticed some console errors during
roslaunch
that I didn't have all the run-time dependencies installed, and it was complaining that some effort controllers could not be loaded. I resolved that withrosdep install -i -y --rosdistro noetic --from-paths src
in my workspace. Now I'm not seeing the noise issues that you were mentioning.I've also tried using the world-step solver, and it seems to work as well:
diff --git a/models/dave_worlds/worlds/dave_ocean_waves.world b/models/dave_worlds/worlds/dave_ocean_waves.world index ec56db4..c2ebcb3 100644 --- a/models/dave_worlds/worlds/dave_ocean_waves.world +++ b/models/dave_worlds/worlds/dave_ocean_waves.world @@ -22,6 +22,11 @@ <max_step_size>0.002</max_step_size> <real_time_factor>1</real_time_factor> <real_time_update_rate>500</real_time_update_rate> + <ode> + <solver> + <type>world</type> + </solver> + </ode> </physics> <scene> <ambient>0.01 0.01 0.01 1.0</ambient>
no sooner did I type this than I started seeing them the next time I launched the simulation. I am still investigating
Side note:
rosdep
error probably related to this https://github.com/Field-Robotics-Lab/dave/issues/188
Although, that's for a host machine install - was that your setup? If so, that would be resolved in that ticket. Two packages were missing from our host installation tutorial.
If you are using dockwater
and had that rosdep
problem, I want to know. We need to fix that.
it was on my host machine setup. I was having too much trouble with dockwater
so I have just been using it on my host machine for now
That makes sense. I think it should be resolved now for new host installations.
I've merged a pull request in gazebo that makes it possible to plot joint velocities for models that use /
in joint names and have recorded screen captures of the improvements provided by the world-step solver in the following pull request: https://github.com/Field-Robotics-Lab/dave/pull/236
Hi guys,
Not sure if this got fixed on the overall. For static bodies, I found that ft_sensor
readings were really tight. But once I start sending position commands to the robot, I found that the ft_sensor
readings were pretty much unreliable.
Is there a PR or some fix for this since you last observed this, @scpeters @mabelzhang?
I believe we found changing to the world solver, as in #236, was sufficient?
To run:
roslaunch dave_demo_launch dave_manipulator_spring_demo.launch
roslaunch dave_demo_launch dave_manipulator_spring_plot.launch
In the below example, the plotting function is showing the shoulder joint.
Observed Issue:
Without Joint Controller
By moving the rexrov up and down we see the arm's shoulder torque changing in correspondence. As well, there is some high frequency oscillation that only occurs when the ROV is not moving. The working theory is that it is caused by the arm bouncing off of the ROV body as there is no controller force to hold it up.
Controller Tuning
We find PID values related to the control of the oberon7 in two locations:
oberon7_control/launch/joint_control.launch
andoberon7_control/launch/joint_effort_controllers.launch
Tuning attempts are ongoing. Initial iterations are based on changing PID values for each joint until oscillations discipate, then moving on to the next joint.