Contact and gazebo_ros_controller issue
Dear Gazebo community
We are a company working on an industrial application of mobile robot. We decided to work with ROS and we are trying to use Gazebo to develop, test and validate algorithms.
We decided to publish a basic version of our robot in order to share it with the community. https://github.com/Stanley-Robotics/PublicStan
The robot urdf is here: https://github.com/Stanley-Robotics/PublicStan/blob/master/src/basic_robot_pkg/urdf/robot_simplified.urdf.xacro
With our robot model we face several issues in gazebo:
- The velocity controller seems to pain to maintain the 0 command when we extend the robot (python script/extend.py) (https://youtu.be/KRg-boKyuiw)
- The robot slide even with huge mu1, mu2 if we set the iteration in gazebo to 50 (the default one) (https://youtu.be/L3Zn2PzAb_o)
- The 4 rear casters of our robot are not touching the ground all the time (https://youtu.be/zbRtseEv3Ss)
- The simulation speed is slow (we would like to have 50 time real time, but we are locked to 2-3 times)
What do you think ? Do you have any advice that could help us about our issues ?
In order to run our simulation please use Gazebo7
git clone https://github.com/Stanley-Robotics/PublicStan.git roslaunch basicrobotpkg gazeboemptyworld.launch roslaunch basicrobotpkg basic_simulation.launch python forward.py/extend.py/rotate.py
Thanks
Asked by GuillaumeB on 2016-09-29 10:39:08 UTC
Answers
you seem to have fixed the first issue. I cannot reproduce it.
I'm not seeing any significant drift. You will not achieve exactly zero drift with gazebo, but the amount I'm seeing is so small (at iterations=200) that it shouldn't matter. The real world isn't perfect either.
The contacts aren't really an issue. they just do that. Also, when I set it to drive forward they did maintain contact constantly.
50x simulation speed is a lot to ask. Try running it without gzclient (just gzserver) and see if that helps. Also, as you've seen, you can mess with solver iterations to try to increase it.
Comment below this if I didn't answer your question.
Asked by Peter Mitrano on 2016-10-03 10:50:55 UTC
Comments
Thank you for your answer. Very weird that you can't reproduce the first issue. I pulled the last version of the code and tried again this morning and the issue was still there. Actually, I would like to have the zero drift behavior but at iteration=50. I thought that it's maybe not possible because of the heavy weight of the robot.
Asked by GuillaumeB on 2016-10-04 06:17:02 UTC
Yea, the scripts all works just fine for me, the robot doesn't split itself in half or anything weird. I would steer you away from relying having exactly zero drift.
Asked by Peter Mitrano on 2016-10-04 12:00:07 UTC
Actually, the robot should extend (split himself). The problem is that when we extend (extend.py) the robot should extend (the second part) but the front wheels should keep the zero velocity (and on the simulation the wheels are rotating, <- that's the issue).
Asked by GuillaumeB on 2016-10-04 13:29:05 UTC
Ok, so unless you explicitly control the position of the joints, the back wheels will spin. Or, you need to set high enough damping so they just don't move on their own. Right now your model has no damping whatsoever, which is not right. Damping should model the resistance in the motor & gearboxes.
Asked by Peter Mitrano on 2016-10-04 16:27:23 UTC
So I tried several value of damping, from 0 to 2147483647. From 0 to ~2000 the wheels continue there rotation, and from 3000 to 2147483647, the robot explode. About the control even if I control the speed to 0, wheels are rotation (during the extend). If I set a velocity_controllers/JointPositionController the wheels can maintain the zero position. Should I avoid JointVelocityController ? However JointVelocityController seems more convinient to control a propulsion wheel.
Asked by GuillaumeB on 2016-10-06 04:58:25 UTC
I'm not sure about JointVelocity controller, but I know damping is usually much smaller than that. <100 for most models I've seen. The easiest thing to use is the joint panel hidden on the far right of gazebo. Using the velocity PIDs there will prove to you that the wheels will stop rotating if you properly control their position/velocity
Asked by Peter Mitrano on 2016-10-06 09:30:28 UTC
I use velocity_controllers/JointVelocityController so I am not setting a PID (it is supposed to be perfect, I think). And when I set the velocity thanks to the right panel with a PID it doesn't seems to work.
Asked by GuillaumeB on 2016-10-07 10:28:59 UTC
I don't think gazebo does "perfect" controllers. If it doesn't work with the PID panel, it's not likely to work. Try loading your model without any plugins, then try the PID panel. Your plugins are probably fighting with the PID panel
Asked by Peter Mitrano on 2016-10-09 18:38:56 UTC
I haven't tested your suggestion yet. I have noticed that if I comment the
Asked by GuillaumeB on 2016-10-17 04:45:37 UTC
nope, sorry. Idk what transmission does. pretty sure that's a urdf thing
Asked by Peter Mitrano on 2016-10-18 18:34:38 UTC
So I tested with the joint/PID panel, and didn't even success to keep my robot not moving. I tried many PID coefficent but didn't succes to do anything.
Asked by GuillaumeB on 2016-10-22 17:04:46 UTC
I fixed my issue, but I don't really know why. I replace in the transmision flag of the pillow_front and pillow_back (in urdf) that was PositionJointInterface by a VelocityJointInterface. By replacing this interface, the extension of the robot stopped making the robot moving forward. In the control.yaml I used a velocity_controllers/JointPositionController as controller so It doesn't change anything from a user point of view.
Why adding a transmission on a joint A interact on the stability of a joint B. And why using a velocity transmission instead of a position transmission solved this interaction. This will probably be the topic of an other question.
Asked by GuillaumeB on 2016-10-24 11:42:06 UTC
Comments