Robotics StackExchange | Archived questions

Parameters for a skid steering/simulated tracked robot (use of the fdir1 tag)

I´m trying to simulate a tracked robot by using multiple wheels and a modified skid steering plugin. It turned out that adjusting the friction parameters is quite tricky for this task.

There has been a lot of discussion on how to make a skid steering robot work in Gazebo in the past, but as far as I can see with no definitive conclusion/guide on how to do so. Some example discussions:

  1. how-do-i-set-up-mu-and-slip-for-a-skid-steer-robot - Gazebo does not work when adding adding slip parameters to by URDF´s gazebo friction parameters
  2. choosing-the-right-coefficients-for-gazebo-simulation
  3. rotation-error-in-gazebo-simulation - It appears after this discussion the fdir1 option has been added

I want to simulate a tracked vehicle using 5 skid steered wheels on each side of it. I have been able to tune the friction parameters a bit and have it working somewhat ok on a Gazebo empty world scenario. To illustrate, this is the robot system:

image description

Visual representation on the left, internal representation (with collision geometry, five interecting wheels per side) on the right. The model is available on github in the hector_tracked_vehicles_description package ("test_fdir1_gazebo_answers" branch). It uses the diffdrive_plugin_multi_wheel available in the "add_diffdrive_multi_wheel" branch of hector_gazebo_plugins. It can be spawned into a gazebo world by running

roslaunch hector_tracked_vehicles_description spawn_jasmine_ugv_base.launch

The parameters I came up with so far for the wheel links are the following (they are set in tracked_wheel.urdf.xacro):

    <mu1>0.9</mu1>
    <mu2>0.9</mu2>
    <kp>1000000.0</kp>
    <kd>10.0</kd>            
    <minDepth>0.001</minDepth>
    <maxContacts>1</maxContacts>

Unfortunately, while working on flat ground, the vehicle is sliding a lot when on inclined/non-flat ground using these parameters. I tried using the fdir1 option, but this appears not to work in the way I understand all the documentation I found (This part of the ODE documentation is by far the best I could find). fdir1 is supposed to be given in the local coordinate frame of the colliding body (e.g. my wheel cylinders). My wheel cylinder is spinning around it´s y axis, so setting

<fdir1>0 1 0</fdir1>

appears to be the only setting that makes sense to me. Using this, it should be possible to set mu to adjust friction in the direction of the y axis and mu2 to adjust friction in the direction of the x axis of the robot (as fdir2 is calculated to be perpendicular to both fdir1 and the contact normal). Unfortunately, setting fdir1 as described (and keeping all other parameters the same) causes the robot to "wobble" while rotating and not stopping rotating when 0 rotational velocity is commanded. It appears this definitely does not work as I thought it should.

My related questions:

  1. Is there a way to get this to work properly using parameter tuning and proper use of fdir1? If so, all hints are appreciated. Also, a page on the gazebo wiki about these issues would probably be a good thing.
  2. Contact is always between two surfaces. So far I only looked at my wheel´s properties. Would it be required to also tune all ground surfaces?
  3. Gazebo would not start up when adding the slip1 and slip2 parameters to my URDF´s gazebo/SDF section. Should this work? If it should, what am I doing wrong?

All this is on Ubuntu 12.04 AMD64/Hydro/Gazebo from .debs

/edit: Linking some related Bitbucket tickets:

Asked by Stefan Kohlbrecher on 2014-02-13 04:31:40 UTC

Comments

I'll take a look at this when I have a chance. My first thoughts are to View Contacts to see if the contact points are jumping around, and also to increase the number of solver iterations to see if that has an effect.

Asked by scpeters on 2014-02-14 14:43:00 UTC

This seems to be related the question I just asked about omni-wheel modeling and fdir1/mu not working properly. (http://answers.gazebosim.org/question/5562/modeling-omni-wheels/). I'll link back to this question as well.

Asked by Gwen on 2014-02-26 12:15:55 UTC

Converting the model to SDF and manually adding 0.0 0.0 to ode element in collision->surface->friction might help, if they haven't been generated in the conversion process (in my case, they were not there). This might change how the model works, but I am not sure it will get the desired results.

Asked by Maxim Rovbo on 2016-01-18 01:39:49 UTC

Answers

I know I'm resurrecting an old thread, but maybe others might still be interested.

Setting fdir1 would be a solution if it worked correctly. For some reason, the direction is not treated as relative to the link, but in world coordinates, so you'd need to update it in every frame to the correct world direction. See https://bitbucket.org/osrf/gazebo/issues/2068/directional-friction-still-broken .

Also, an omni-wheel needs the most precise friction computations that are available to work properly. Recently, the friction_cone model was added, which helped a lot in my case:

physics::PhysicsEnginePtr physics = world->GetPhysicsEngine();
const std::string frictionModel = "cone_model";
physics->SetParam("friction_model", frictionModel);

Last, a bit unrelated, but nevertheless, now there's (my) PR to add proper support of tracked vehicles. Everybody's welcome to try it out. https://bitbucket.org/osrf/gazebo/pull-requests/2652/added-support-for-tracked-vehicles

Asked by peci1 on 2017-03-16 13:40:56 UTC

Comments

Hey peci1 I also would like to model omni-wheels do you have a complete working example?

Asked by markus on 2017-12-03 05:22:19 UTC