Mecanum wheels ok in one direction not the other in Gazebo
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)
- continuous / revolute joint 1 (its axis is the axis of the wheel – or motor, this is the joint which is actuated)
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...
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...
I wasn't able to view your dropbox files. Are they still working?
Also, there's not an easy way to increase the number of sides in the ODE contact pyramid.
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 ;)
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...
Switching to bullet will be worse. Please try, but bullet is not going to improve anything.
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!