hsu's profile - activity

that would be the position controller in ros_control calling SetPosition

Use POSITION_PID instead of POSITION should help.

yes, please see my comment in http://answers.gazebosim.org/question/15045/why-my-model-seems-to-defy-the-gravity-and-seems-to-be-grabbed-from-the-top-when-moving/

position control breaks laws of dynamics by teleporting parts around. you are seeing the effect of that propagating to the whole model. if you are using ROS control, the is an effort based position controller that I highly recommend. after that, it's all about making sure things are physically realistic as a starting point. that will get you a working albeit not necessarily efficient model. then the next step is to optimize for performance.

what kind of controllers are you using?

do you have position controllers running on the arm? if a controller is calling Joint::SetPosition or SetVelocity to the arm joints, it will interfer with dynamics.

please provide example complete with kp, kd, soft_cfm and soft_erp.

Without diving in deeper into dynamics, I noticed that finger inertias have zero MOI, this is a specialized case that we have not explored much in gazebo. Can you assign realistic finger inertia complete with finite MOI?

have you tried to model soft contact using params first? I am sure we can get stable soft contact by just setting up the model right. You'll get a much more predictable simulation this way. Using mud plugin is not designed to do what you are suggesting here.

Some suggestions:

1) add following blocks to your urdf for every joint:

  <gazebo reference="[joint name]">
    <implicitSpringDamper>1</implicitSpringDamper>
  </gazebo>

Sometimes I think we should have these settings on by default.

Also, try to come up with as realistic as possible material properties kp, mu1, mu2. Set contact dissipation coefficient kd to 1 to help stabilize contacts. Also, setting minDepth margin to a small non-zero number prevents contact from jumping in and out of existence. For example:

<gazebo reference="[links in contact]">
  <kp>1000000.0</kp>
  <kd>1.0</kd>
  <mu1>1.0</mu1>
  <mu2>1.0</mu2>
  <minDepth>0.001</minDepth>
</gazebo>

2) The cylinder has mass value of 0.1kg, but Ixx of 1.0 kg m^2, which is not very physically realistic. One should always start with a more physically realistic object model.

3) As a rule of thumb, if the inertia ratio across contact constraint formed by the object and the gripper finger is on the order of or greater than 1e3, consider increasing number of inner iterations from default of 50, do a quick ad-hoc search by doubling iterations and look for improvement in behavior. Alternatively, plot iterations vs rms_error and check trend.

4) Consider increasing joint damping for the fingers. Without modeling high gear ratio gearbox joints and the underlying motor and gear inertia, the stabilizing effects of such mechanisms is easiest replaced by larger joint damping in the time being. Physically, my go to damping coefficient for triaging a hard to converge system ranges anywhere between 0.1 to 30 (effort/joint_vel). Until such time validation or more accurate model data are available.

5) Are the joint effort limits realistic? 0.1N seems low for holding up a 0.1kg cylinder (under gravity, downward force is 9.81N).

6) Consider tuning the PID gains of your controller. We can go into details on this as needed.

did you try one of the Inertial::SetCoG calls?

here are a couple of sources of undesired "bouncing behavior" that I've commonly seen with vehicles:

• cause: interpenetration correction applies an impulse that pushes the object away from interpenetrating collision, but if the impulse is too large it causes the object to "bounce/fly away". fix: set maximum velocity impulse (max_vel) to 0 will enforce pure position correction with no added momentum from interpenetration correction. It is recommended to set a finite minimum allowable interpenetration depth (min_depth) of 1mm or something small in comparison to the colliding objects.
• cause: controller exerts unrealistically large efforts on joints or links. fix: double check the forces/torques commanded by your controller and make sure they are physically realistic if you are looking for physically realistic responses.
• cause: unrealistically high velocity / momentum buildup. fix: add dissipation by adding joint damping and set implicit_spring_damper flag to true to avoid numerical instability. Joint damping value is in the units of (effort / velocity). One extremely simplistic way to try and come up with viscous damping estimates is this: at what joint velocity do you want significant effort opposing your actuation forces? Assuming for example, we are controlling a hinged joint, and the actuator is capable of putting out 1 Nm of torque. A damping coefficient of 2 means the damping force opposing your actuator will neutralize actuation torque of 1 Nm when the joint is rotating at 0.5 rad/s.
• cause: friction coefficients are too large, combined with failure of dynamics solver to resolve all constraints sufficiently in allotted time. This is especially true of you have opposing frictional forces at work such as in the cases of skid-steer or non-ackerman steering. fix: use friction coefficient of 1 or lower, and potentially increase number of inner iterations.

Here's an example for specifying contact parameters discussed above in URDF as Gazebo extensions, this example applies the parameters to all collision shapes specified under a link named my_link:

<gazebo reference="my_link">
  <kp>1000000.0</kp>
  <kd>1.0</kd>
  <mu1>0.8</mu1>
  <mu2>0.8</mu2>
  <maxVel>0.0</maxVel>
  <minDepth>0.001</minDepth>
</gazebo>

Is it just loading time that's slow? or is simulation speed also slow? You can check simulation speed while simulation is running, by running `gz stats` in a different terminal, it should report the real-time factor.

what GPU are you using? If you have Radeon GPU, in my experience only proprietary fglrx drivers work.

repeating what @nkoenig says about

gazebo --verbose

also, the BadDrawable error is usually seen with unsupported GPU. If that's the cause, you can only run headless. To force headless mode, unset the DISPLAY environment variable then run gzserver with verbose flag:

$ unset DISPLAY
$ gzserver --verbose
Gazebo multi-robot simulator, version 7.1.0
Copyright (C) 2012-2016 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 172.23.1.164
[Err] [RenderEngine.cc:699] Can't open display: 
[Wrn] [RenderEngine.cc:97] Unable to create X window. Rendering will be disabled
[Wrn] [RenderEngine.cc:301] Cannot initialize render engine since render path type is NONE. Ignore this warning ifrendering has been turned off on purpose.

gazebo should be running but without any rendering capabilities enabled. You can open a different terminal and run gz stats to confirm and check performance, for example:

$ gz stats
Factor[1.00] SimTime[5.67] RealTime[5.70] Paused[F]
Factor[1.00] SimTime[5.88] RealTime[5.90] Paused[F]
Factor[1.00] SimTime[6.07] RealTime[6.10] Paused[F]

Yes, the position based control (e.g. https://github.com/ros-simulation/gazebo_ros_pkgs/blob/jade-devel/gazebo_ros_control/src/default_robot_hw_sim.cpp#L300) will negate dynamics (i.e. ignore gravity or external forces)

Continuous joints are revolute joints without limits. Perhaps you are looking for behaviors of a prismatic joint?

as demonstrated in this test Join::SetForce is not cumulative, the moment you stop calling it the joint becomes passive.

I don't think torques are accumulated via Joint::SetForce. Can you please share how you arrived at that conclusion? Thanks. Ref example for ode: https://bitbucket.org/osrf/gazebo/src/76f21ee32c3db6edeb5a7213e00c4ed223e4b815/gazebo/physics/ode/ODEHingeJoint.cc?at=default&fileviewer=file-view-default#ODEHingeJoint.cc-153

because rolling friction is usually not a very large force, the need to implement it as a constraint is not high. Nate's suggestion as a plugin and apply a force based on object's current dynamics may be sufficient.

ODE does not support rolling friction right now. This could be added similar to torsional friction (see https://bitbucket.org/osrf/gazebo/pull-requests/1831/torsional-friction/diff), but with 2 major differences: 1) constraint direction parallel to object's rotational axis projected to a plane normal to the contact normal. 2) rolling friction coefficient definition.

is the robot controller active when it's sliding? if yes, is the behavior still there when you turn off the controllers? If no, can you isolate the model by itself as a standalone gazebo model? Either way, what commands does one run to reproduce the behavior? thanks.

In addition to setting high friction coefficient, you want to make sure the surface elasticity (kp), damping (kd) and in most cases, allow for minimal interpenetration (min_depth) gives you stable contact without high frequency errors. If contact visualization shows flickering blue line (magnitude of contact force), that indicates the contact is not stable, there are high frequency errors that will cause friction to behave incorrectly. Take a look at this example world of boxes sliding down a 45° incline (tilt gravity):

https://bitbucket.org/osrf/gazebo/src...

Where we get exactly whats expected of friction forces. Another example to demonstrate stable contact by using min_depth:

https://bitbucket.org/osrf/gazebo/src...

Lastly, another more complex example with Atlas feet:

https://bitbucket.org/osrf/drcsim/src...

We modeled (in order of magnitude) after rubber material and got stable contact. When in doubt, start with parameters of real materials, then post back on the forum if you run into more issues.

Some materials have friction coefficients >1 (~1.1), so you can do that. Minor note: friction coefficient of 1+ does not mean it will never slide, but it is very "sticky".

updating the answer with a response. Thanks.

Please provide sdf with realistic inertia. It's better if we debug the real robot to figure out what the issue is.

== respond to comment below ==

I personally prefer starting with a realistic model, find out why dynamics is not behaving correctly (deal with all the problem such as "exploded all over the place" is fixable). You'll be surprised the issues you saw before changing inertia might not be a completely different problem at all; as numerical errors have a strange way of exposing themselves sometimes.

Normally, in addition to realistic inertia, I'd ask for realistic estimates of friction, joint damping, actuation details, etc. Those things are optional because we can estimate them to the right order of magnitude by simple assumptions for now. But provide them as a bonus if you have them.

With a working as-realistic-as-possible model as a baseline, we can then make additional trade-offs for performance by tweaking the model physically.

I personally don't think debugging a brand new robot with physically non-realistic parameters is a good approach. The direction of gravity issue might come from various unexpected side effects of numerical updates for one

Thanks.

recommendation: 1) test if gravity is active without the controller. 2) if 1 works, the problem is in the controller. otherwise 3) update question to contain a world or model file that does not have the controller, with gravity turned off, yet gravity is still active.

updated my PR (note on 12.04, only up to gazebo4 debian is available).

https://bitbucket.org/osrf/gazebo_tutorials/pull-requests/352/tutorial_7-0md-edited-online-with/diff

generic answer is yes... but to answer more precisely, please elaborate on what is meant by "parallel robots"; do you mean parallel platforms similar to Stewart Platforms or something else? Also, what kind of "cable robots", are these cable / pulley driven transmissions? What types of loads and degree of accuracy is desired?

the <gazebo> extension tags are not passed to sdf, issue has been created to track this missing feature: https://bitbucket.org/osrf/sdformat/issues/edit/112

You could use additional options from spawn_model (-z 0.5):

$ rosrun gazebo_ros spawn_model 
Commands:
    -[urdf|sdf|trimesh|gazebo] - specify incoming xml is urdf, sdf or trimesh format. gazebo arg is deprecated in ROS Hydro
    -[file|param|database] [<file_name>|<param_name>|<model_name>] - source of the model xml or the trimesh file
    -model <model_name> - name of the model to be spawned.
    -reference_frame <entity_name> - optinal: name of the model/body where initial pose is defined.
                                     If left empty or specified as "world", gazebo world frame is used.
    -gazebo_namespace <gazebo ros_namespace> - optional: ROS namespace of gazebo offered ROS interfaces.  Defaults to /gazebo/ (e.g. /gazebo/spawn_model).
    -robot_namespace <robot ros_namespace> - optional: change ROS namespace of gazebo-plugins.
    -unpause - optional: !!!Experimental!!! unpause physics after spawning model
    -wait - optional: !!!Experimental!!! wait for model to exist
    -trimesh_mass <mass in kg> - required if -trimesh is used: linear mass
    -trimesh_ixx <moment of inertia in kg*m^2> - required if -trimesh is used: moment of inertia about x-axis
    -trimesh_iyy <moment of inertia in kg*m^2> - required if -trimesh is used: moment of inertia about y-axis
    -trimesh_izz <moment of inertia in kg*m^2> - required if -trimesh is used: moment of inertia about z-axis
    -trimesh_gravity <bool> - required if -trimesh is used: gravity turned on for this trimesh model
    -trimesh_material <material name as a string> - required if -trimesh is used: E.g. Gazebo/Blue
    -trimesh_name <link name as a string> - required if -trimesh is used: name of the link containing the trimesh
    -x <x in meters> - optional: initial pose, use 0 if left out
    -y <y in meters> - optional: initial pose, use 0 if left out
    -z <z in meters> - optional: initial pose, use 0 if left out
    -R <roll in radians> - optional: initial pose, use 0 if left out
    -P <pitch in radians> - optional: initial pose, use 0 if left out
    -Y <yaw in radians> - optional: initial pose, use 0 if left out
    -J <joint_name joint_position> - optional: initialize the specified joint at the specified value

So something like this could work:

 <param name="robot_description" 
   command="$(find xacro)/xacro.py '$(find my_robot_description)/urdf/my_robot.xacro'"/>
<node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
  args="-z 0.5 -urdf -model my_robot -param robot_description"/>

On the other hand, I like the suggestion of supporting robot extensions that goes directly under the model tag, issued

https://bitbucket.org/osrf/sdformat/i...

which version of sdformat and urdf are you running? There are some examples in the unit tests, see equivalent examples in https://bitbucket.org/osrf/sdformat/src/753c70f286d59790160cf458ad18fa322def0691/test/integration/fixed_joint_reduction_collision_visual_extension.urdf?at=default and https://bitbucket.org/osrf/sdformat/src/753c70f286d59790160cf458ad18fa322def0691/test/integration/fixed_joint_reduction_collision_visual_extension.sdf?at=default

This is an update to an old thread, as of today (Feb 16, 2016) there is no native transmission or actuator tags in SDF. Some beginning discussions on how to generalize actuators/transmission into SDF be found here https://bitbucket.org/osrf/gazebo_design/src/090bd9e7997523a97002ca55b2ac253b612845d6/transmission/transmission.md?fileviewer=file-view-default , inputs welcome.

Another example in a world plugin handsim/src/b6415df144217a6bf40b3f2265ae3ca079b89bfd/src/HaptixWorldPlugin.cc?at=default&fileviewer=file-view-default#HaptixWorldPlugin.cc-1357

make damping implicit by adding

<gazebo reference="front_left_axel">
  <implicitSpringDamper>1</implicitSpringDamper>
</gazebo>

to your model.

Or for example in SDF for ODE:

<joint name="front_left_axel" type="revolute">
    ...
    <physics>
        <ode>
            <implicit_spring_damper>1</implicit_spring_damper>
        </ode>
    </physics>
</joint>