# Revision history [back]

### Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

Dear all,

the problem stated in the title of this question is a real blocker for us at the moment.

What we try to do:
Our setup is: Trusty, Indigo, gazebo2_2.2.3-1~trusty_amd64

We try to simulate two 7-DoF arms:
- Schunk lwa4d
- Schunk lwa4p
Models can be found here for lwa4d and here for lwa4p_extended

We try to control those robots using velocity_controllers/JointVelocityControllers which uses the VelocityJointInterface hardware interface (specified in transmission). Velocity commands will finally be sent from a higher level node. For testing we simply use a terminal publisher or rqt.

To reproduce the behaviour described below, there exist convenience "bringup"-packages containing all launch- and config files here.

Simply run either
roslaunch schunk_lwa4d lwa4d_sim_urdf.launch or
roslaunch schunk_lwa4p_extended lwa4p_extended_sim_urdf.launch respectively.

The problem we are having
It seems that (for some) joints, the velocity commands cannot be executed by the simulated robot. I.e. the current joint velocity (as published in /joint_states/velocity differs from the velocity command being send from the (forward command) controller velocity_controllers/JointVelocityController (on topic /arm_X_joint_velocity_controller/command).

The following videos visualize the current behaviour.
In video1 it can be seen that arm_2_joint of the Schunk lwa4p_extended already starts to drop/drift right from the beginning of the simulation, i.e. whon no velocity command has yet been send and thus goal velocity is 0.0 for all joints.
In video2 it can be seen that also commanding velocities != 0.0 are not executed correctly.
However in video3 it can be seen that velocity commands actually can be executed without dropping/drifting.

What we already tried to fix it
Of course, I found the following related threads on this list:

• In this thread and this thread it is suggested to check SetMaxForce. However, as I am using the gazebo_ros_control plugin with DefaultRobotHWSim hardware interface, the value passed to Joint::SetMaxForce is received from the effort limit in the URDF. We use values from the technical data sheets of our motors for our model but of course also tested (arbitrarily) higher values - without success.

• In this thread the problem was caused by a wrong inertia tag in the URDF. However, in our models, we use inertias derived from CAD data. We also tried to use "simplified" approximations for the inertias using these macros - again: no success.

We also played around with the meshes used for our models in order to guarantee they don't collide thus causing unexpected forces to the joints - again: no success.

It's really frustrating, as I don't have any more ideas what could be causing this strange behaviour.
But as it seems to actually be possible to command joints by sending velocity commands with SetVelocity (see lwa4d arm_2_joint), it doesn't seem to be a general problem with Joint::SetVelocity.

Could it be that it has something to do with which PhysicsEngine I use? With gazebo2 I have been using ODE only. I found this issue related to Bullet which made me wonder whether it is safe to assume SetVelocity can be expected to work.

• Is there any known bug in gazebo2 that has been fixed in one of the later versions gazebo3/gazebo4?

• Could anyone (of the main developers) confirm that SetVelocity is working properly. Or confirm that it is not?

What other possible solutions could we test in order to pin down the source of error? Any ideas?

I'll gladly send a bar of chocolate to anyone able to help!

Thanks!

### Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

Dear all,

the problem stated in the title of this question is a real blocker for us at the moment.

What we try to do:
Our setup is: Trusty, Indigo, gazebo2_2.2.3-1~trusty_amd64

We try to simulate two 7-DoF arms:
- Schunk lwa4d
- Schunk lwa4p
Models can be found here for lwa4d and here for lwa4p_extended

We try to control those robots using velocity_controllers/JointVelocityControllers which uses the VelocityJointInterface hardware interface (specified in transmission). Velocity commands will finally be sent from a higher level node. For testing we simply use a terminal publisher or rqt.

To reproduce the behaviour described below, there exist convenience "bringup"-packages containing all launch- and config files here.

Simply run either
roslaunch schunk_lwa4d lwa4d_sim_urdf.launch or
roslaunch schunk_lwa4p_extended lwa4p_extended_sim_urdf.launch respectively.

The problem we are having
It seems that (for some) joints, the velocity commands cannot be executed by the simulated robot. I.e. the current joint velocity (as published in /joint_states/velocity differs from the velocity command being send from the (forward command) controller velocity_controllers/JointVelocityController (on topic /arm_X_joint_velocity_controller/command).

The following videos visualize the current behaviour.
In video1 it can be seen that arm_2_joint of the Schunk lwa4p_extended already starts to drop/drift right from the beginning of the simulation, i.e. whon no velocity command has yet been send and thus goal velocity is 0.0 for all joints.
In video2 it can be seen that also commanding velocities != 0.0 are not executed correctly.
However in video3 it can be seen that velocity commands actually can be executed without dropping/drifting. (Beside the strange behaviour of arm_6_joint! As this is also of the same motor type as used in the lwa4p_extended, I assume that the behaviour of that arm_6_joint has similar reasons.)

What we already tried to fix it
Of course, I found the following related threads on this list:

• In this thread and this thread it is suggested to check SetMaxForce. However, as I am using the gazebo_ros_control plugin with DefaultRobotHWSim hardware interface, the value passed to Joint::SetMaxForce is received from the effort limit in the URDF. We use values from the technical data sheets of our motors for our model but of course also tested (arbitrarily) higher values - without success.

• In this thread the problem was caused by a wrong inertia tag in the URDF. However, in our models, we use inertias derived from CAD data. We also tried to use "simplified" approximations for the inertias using these macros - again: no success.

We also played around with the meshes used for our models in order to guarantee they don't collide thus causing unexpected forces to the joints - again: no success.

It's really frustrating, as I don't have any more ideas what could be causing this strange behaviour.
But as it seems to actually be possible to command joints by sending velocity commands with SetVelocity (see lwa4d arm_2_joint), it doesn't seem to be a general problem with Joint::SetVelocity.

Could it be that it has something to do with which PhysicsEngine I use? With gazebo2 I have been using ODE only. I found this issue related to Bullet which made me wonder whether it is safe to assume SetVelocity can be expected to work.

• Is there any known bug in gazebo2 that has been fixed in one of the later versions gazebo3/gazebo4?

• Could anyone (of the main developers) confirm that SetVelocity is working properly. Or confirm that it is not?

What other possible solutions could we test in order to pin down the source of error? Any ideas?

I'll gladly send a bar of chocolate to anyone able to help!

Thanks!