Home | Tutorials | Wiki | Issues
Ask Your Question
0

Mecanum wheels ok in one direction not the other in Gazebo

asked 2014-09-20 06:45:50 -0600

arennuit gravatar image

updated 2014-09-23 01:54:25 -0600

Hi all,

This looks like a problem of contacts simulation parameters... Let me give more details:

I am currently trying to emulate mecanum wheels using ros indigo and gazebo 2.2 thanks to a trick I found in the VREP implementation of the youbot (see here). They actually use the hierarchy shown below for a single wheel and update the direction of the axis of revolute joint 2 at each frame:

Hierarchy for a wheel:

  • mobile platform base link
    • continuous / revolute joint 1 (its axis is the axis of the wheel – or motor, this is the joint which is actuated)
      • visual representation of the wheel (this is the mesh of the mecanum wheel)
      • dummy collision and inertia
      • continuous / revolute joint 2 (its axis is oriented at 45°, along the direction of the contacting roller and crosses the COM of the wheel)
        • collision geometry (this is a collision sphere)

I implemented this hierarchy for each wheel (urdf file here or here) and coded a gazebo plugin which performs the axis alignment computation (plugin code here or here). The system turns out to work ok when moving in the principal direction of the mobile robot (all mecanum wheels turn in the same direction), but when attempting to move sideways (2 opposite mecanum wheels rotating in one direction the two others in the opposite direction), the mobile robot moves as expected for a few frames but then goes back and forth in a way which is not realistic. It looks like a problem with contacts so I played a bit with the mu, kp and kd values of the link in contact with the floor but that did not help.

I have put some videos illustrating the working case when going frontwards (video here) and the problematic case when going sideways (video here). The simulations are stepped by hand to better show the problem.

On the second video (problematic case), the torque applied to the wheels is constant during the whole course of the simulation, hence the mobile movement should be sideways in the up direction. But we observe the wheels accelerate / slide before the mobile platform changes direction back and forth (up and down on the screen). This is very unintuitive.

If I replace the mecanum wheels with normal wheels, all is as expected. The orientation of wheel axes realigned at each step look fine from the printfs.

I am not sure what to do and feel a bit lost... Anyone has an idea of what I could change to improve things?

Thanks,

Antoine.

------ UPDATE -------

The urdf and plugin files can alternatively also be found here and here. Or here.

Also, I have just tried lowering the mu value for the chassis and rollers (chassis_link_sdf_mu and roller_link_sdf_mu) to 0.2 rather than 1.0, as I read some posts saying it could help, but in my case it did not change much...

edit retag flag offensive close merge delete

Comments

After investigating, it looks like it could be related to the linear approximation of contact cones in ODE (cones are approximated by pyramids). e.g. http://answers.ros.org/question/9640/rotation-error-in-gazebo-simulation/. I have tried playing with fdir1 though this is does not improve thing... Is there a way to increase the number of sides to the contact pyramid? I could not find anything related...

arennuit gravatar imagearennuit ( 2014-09-22 07:52:14 -0600 )edit

I wasn't able to view your dropbox files. Are they still working?

scpeters gravatar imagescpeters ( 2014-09-22 11:15:20 -0600 )edit

Also, there's not an easy way to increase the number of sides in the ODE contact pyramid.

scpeters gravatar imagescpeters ( 2014-09-22 11:49:01 -0600 )edit

Hi Peters, I have just added other links for the xacro and cpp files here and here. And you can also access these same files from here. Merci ;)

arennuit gravatar imagearennuit ( 2014-09-22 15:59:59 -0600 )edit

This does not make sense to me, I have tried everything obvious and nothing seems to improve the situation... Either I have missed something obvious or I am reaching the limits of ODE. I am thinking about switching to bullet now...

arennuit gravatar imagearennuit ( 2014-09-24 02:56:14 -0600 )edit

Switching to bullet will be worse. Please try, but bullet is not going to improve anything.

nkoenig gravatar imagenkoenig ( 2014-10-07 17:48:07 -0600 )edit

This is interesting, and indeed you are right, it appears the limit does not come from the simulation engine but from the possibility to change the frame of a link/joint without moving the link joint. Thanks for the reply!

arennuit gravatar imagearennuit ( 2014-10-08 01:04:27 -0600 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2016-12-22 16:08:47 -0600

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

new to all this but thought I could simulate a mecanum wheel by adding a rotational joint about z-axis for each wheel that is restricted to 0, 45 and 90 degrees. this way the base can go forward/backward/45 degree forward/backward and left/right, sideway left/right and rotate left/right. the simulated moves would need to translate into rotational direction sets for the physical movements of the 4 wheel motors? however - how can I have a restricted set of angels for a joint and what needs to be in place to translate it into the physical wheel rotation command? of course the simulation would only provide a logical wheel view and it will also need a special collision handling as the wheels do not really rotate on the z-axis. but in total an easy representation of the possible moves?

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

Stats

Asked: 2014-09-20 06:45:50 -0600

Seen: 1,000 times

Last updated: Sep 23 '14