Robotics StackExchange | Archived questions

Custom 4 wheel robot going backward

Hi, I've made a custom robot model in gazebo with 4 wheel. I used gazeboroscontrol to control 4 wheel separately. here is one of the example:

<transmission name="${name}_transmission" type="SimpleTransmission">
  <type>transmission_interface/SimpleTransmission</type>
  <joint name="${name}_joint">
    <hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
  </joint>
  <actuator name="${name}_motor">
    <hardwareInterface>hardware_interface/VelocityJointInterface</hardwareInterface>
    <!--hardware_interface/EffortJointInterface-->
    <mechanicalReduction>10</mechanicalReduction>
  </actuator>
</transmission>

when i launch the gazebo, robot goes backward a bit by bit, very slowly.

    header: 
seq: 1778
  stamp: 
    secs: 35
    nsecs: 973000000
  frame_id: ''
name: - left_back_wheel_joint
- left_front_wheel_joint
- right_back_wheel_joint
- right_front_wheel_joint
position: [-0.003141305783456616, -1.1831937287709593e-05, -0.0019454167338839312, -4.350494892335632e-06]
velocity: [-0.000171673603876349, -0.00015815614100299791, -9.107017547230386e-05, -0.00012163253784832723]
effort: [0.0, 0.0, 0.0, 0.0]

here is my pid example:

right_back_wheel_controller:
    type: velocity_controllers/JointVelocityController
    joint: right_back_wheel_joint
    pid: {p: 10.0, i: 0.01, d: 0.1}

what is the problem there?

Asked by ridwan on 2020-07-15 12:06:36 UTC

Comments

I had a same issue and the reason it was happening was the Gazebo world. I had one world where there was no drift backwards and another one where I had the same behavior that you describe. So the reason was something with the physics inside the .world file. Try another world and see if that changes

Asked by kosmastsk on 2020-07-15 12:50:23 UTC

it still gives some,

header: seq: 5362 stamp: secs: 6031 nsecs: 66000000 frame_id: '' name: - left_back_wheel_joint - left_front_wheel_joint - right_back_wheel_joint - right_front_wheel_joint position: [-0.00895766188413738, -0.00010029614281670263, -0.0037137861694445107, -5.215430933613874e-05] velocity: [-1.790139788460453e-09, 0.00015371939159806736, -6.087800114257582e-10, 5.4862705390444695e-05] effort: [0.0, 0.0, 0.0, 0.0]

Asked by ridwan on 2020-07-15 14:44:48 UTC

Hi @ridwan,

The robot is "technically" going backwards but that is not the result of the controller but as @kosmastsk, is a problem of you Gazebo world. You will need to configure properly Gazebo contacts and wheel params. Nevertheless, you will always end up with those kind of values since it is the nature of the Gazebo contact computation algorithm.

Asked by Weasfas on 2020-07-17 03:37:00 UTC

hi @Weasfas , so what can i do to prevent this type of problem?

Asked by ridwan on 2020-07-17 06:38:07 UTC

Hi @ridwan,

In order to decrease this type of behaviour you can do several things:

  1. Parametrize properly your contact coefficient for your wheels and your floor: In particular I am refering to the coefficients mu1 and mu2 as well as kp and kd. You can check what those values mean here and here. As well as in the SDF documentation.
  2. You can also try to tune the physics parameters from ODE engine used by Gazebo. Kp and Kd params have a direct repercusion over ODE inner params called ERP and CFM used to balance the inestability of the simulation. You can learn more about his params here.

Asked by Weasfas on 2020-07-17 12:40:05 UTC

And finally from the physics tag of SDF format you can try to adjust the iters parameter. The higher the more precission the engine have when calculating contacts.

All this will let you tune your enviroment to try to decrease this behaviour but you need to know that it is very common to see this this when dealing with Gazebo contacts.

Asked by Weasfas on 2020-07-17 12:42:14 UTC

Answers

That motion you observe is probably just some random motion that occurs when your actuators are actually not actuated at all. The fact that the joint efforts seem to be zero indicates that too.

Maybe the controllers just do nothing. You can try to send commands to the controllers. You can do this by manually publishing commands to the controller's command topic. Also have a look at the rqt GUI approach. You may want to revisit the tutorial sections on sending commands here: http://gazebosim.org/tutorials/?tut=ros_control

Maybe the joints' safety limits prevent the controllers to do anything. Check if the URDF specifies nonzero safety limits for effort and velocity for the respective joints. Related: https://answers.ros.org/question/275462/what-is-the-meaning-of-the-effort-or-velocity-on-urdf-model/

If the controllers are actually working, but the resulting movement is reverse, consider to flip the wheels by 180° in the URDF description to invert the direction of positive rotation angles.

Asked by moooeeeep on 2020-08-04 07:43:16 UTC

Comments