A turnning control bug in Kinetic?

[lossemotion]

I use keyboard_teleop to send messages to the topic cmd_vel to control husky to turn left or right in place (press' j 'or' l 'all the time) in gazebo. The normal result should be husky rotate in place or go round with a radius, but the situation of my car is. If I keep the default settings (only a laser enable), Husky is good, but if I set it to Kinect enable or laser disenable, Husky will turn 90 degrees and then go straight. I checked the content of cmd_vel and found that there was no error. The friction coefficient of the tire and the ground was also correct (both were 1). The rotation direction of the tire is also right, but it seems that the traction of the right tire is greater, which dominates the movement direction of husky. What's the reason?

[h3ct0r]

Hi, @lossemotion I'm having a similar issue, did you find the solution?
In my case the robot does not turn exactly in place in Gazebo, it does a weird go left - go front - go back - go left motion!. As seen in this video: Youtube video with the Husky trying to perform an in-place rotation.

Regards!

[lossemotion]

Hi, @h3ct0r You can check if your friction coefficients of the four tires are same first.

As I have described above, I suspected that the traction of the right tire is bigger than the left, so I set the friction coefficients of the right tires as 0.5 and the left remains at 1，then it works fine……

It's strange. I can't explain the solution.

[civerachb-cpr]

Would you mind sending us a pull request with the changes you made so we can look into this further?

[And1210]

I was able to do something similar to @lossemotion. I have been testing changing the coefficient of friction of the wheels. There are 2 coefficients of friction, mu1 and mu2. mu1 deals with friction in the direction of motion so this should be left at 1.0. mu2 on the other hand deals with friction perpendicular to the direction of motion. Setting mu2 to 0.75 or 0.5 seems to help alot. I think this is because the robot wheels are catching on the ground while turning and not able to slip enough to turn properly. You can set this value in the husky description package. Do the following:

roscd husky_description
sudo vim urdf/wheel.urdf.xacro

The value for mu2 should be on line 51. Change it to either 0.5 or 0.75 (test which one works, I am currently working on determining the best value). Note that you will need sudo permission to edit this file.

[civerachb-cpr]

Thanks for the information. I just tried it out on my system and 0.75 definitely seemed to perform better than 0.5; with 0.5 I ran into problems getting the robot to reliably turn counterclockwise, but these issues weren't present with mu2 set to 0.75.

[civerachb-cpr]

Also, a potentially less-destructive way of making the changes (rather than sudo-editing the files in your main installation folder) would be to clone this git repo into a catkin workspace, building it, and running source devel/setup.bash before launching the simulation. That way you can make changes with the safety-net of being able to roll back to an earlier commit.

[And1210]

Thanks for the information. I just tried it out on my system and 0.75 definitely seemed to perform better than 0.5; with 0.5 I ran into problems getting the robot to reliably turn counterclockwise, but these issues weren't present with mu2 set to 0.75.

Ok good to hear! I havent tested on anything but my desktop so Im glad this is working for others. What surface were you driving the husky on? I know mu2=0.5 wasn't working great in the husky_playpen world but on Gazebo's generic ground plane it seemed to work pretty well.

[civerachb-cpr]

I was using the playpen simulation.

[civerachb-cpr]

Closing due to inactivity.

[shendry29]

Can confirm that @And1210's suggestion of mu2=0.5 on Gazebo's default ground works well. I'd also like to add that another compounding factor for me was the unequal distribution of my custom payload. The nonsymmetrical inertial tensor paired with wheels of equal mu2 values resulted in suboptimal performance while turning. Afaik equal mu2 values implies equal weight distribution among the wheels, which was not my case. I tested by removing the inertial tags of my extra elements and immediately saw a better performance.