Gazebo | Ignition | Community
Ask Your Question

fjmorenom's profile - activity

2016-01-20 00:26:35 -0500 received badge  Famous Question (source)
2014-12-06 05:18:32 -0500 received badge  Notable Question (source)
2014-10-08 09:43:52 -0500 received badge  Popular Question (source)
2014-09-12 10:09:48 -0500 asked a question Why won't my model follow the velocities when using setVelocity?

I'm currently working with a robotic arm using ros_control and Gazebo. I'm trying to use JointVelocityControllers using VelocityJointInterface to control the arm. In this case the gazebo_ros_control package uses Joint::SetVelocity to "apply" the velocities to the model. Shouldn't this make the model follow exactly the velocities that I send? (like when using Joint::SetAngle, of course taking into account that this bypasses the physics) I know the maximum force should be specified with setMaxForce(...) and that this value should be quite large, but it doesn't matter how large I set this force, the model won't execute the velocities correctly, not even close to saying acceptable (but also not so bad to say that it is not trying to follow them). For example, when I send the value 0, it remains standing for a while, but after 40 seconds it falls. Any ideas as why this could be happening?

With the file in the link below you should be able to start the model by using:

roslaunch schunk_lwa4p_extended lwa4p_extended_sim_velocityinterfaces.launch

The file is here. The model is located in: schunk_modular_robotics/schunk_description/urdf/lwa4p_extended. There you can change the values of the joint limits (which are used for setMaxForce(...)) and see that the arm will still fall, or not execute the velocites correctly, even with huge values.

BTW, I'm using ROS Hydro on Ubuntu 12.04.

2014-08-27 22:08:18 -0500 received badge  Notable Question (source)
2014-08-14 03:07:44 -0500 commented question How can I make the model follow EXACTLY the velocities that I want?

Model posted! And updated question description.

2014-08-13 10:45:01 -0500 received badge  Popular Question (source)
2014-08-13 07:47:46 -0500 received badge  Editor (source)
2014-08-12 10:09:13 -0500 asked a question How can I make the model follow EXACTLY the velocities that I want?

I'm currently working with a robotic arm using ros_control and Gazebo. I'm trying to use JointVelocityControllers using VelocityJointInterface to control the arm. In this case the gazebo_ros_control package uses Joint::SetVelocity to "apply" the velocities to the model. Shouldn't this make the model follow exactly the velocities that I send? (like when using Joint::SetAngle, of course taking into account that this bypasses the physics) I know the maximum force should be specified with setMaxForce(...) and that this value should be quite large, but it doesn't matter how large I set this force, the model won't execute the velocities correctly, not even close to saying acceptable (but also not so bad to say that it is not trying to follow them). For example, when I send the value 0, it remains standing for a while, but after 40 seconds it falls. Any ideas as why this could be happening?

With the file in the link below you should be able to start the model by using:

roslaunch schunk_lwa4p_extended lwa4p_extended_sim_velocityinterfaces.launch

The file is here. The model is located in: schunk_modular_robotics/schunk_description/urdf/lwa4p_extended. There you can change the values of the joint limits (which are used for setMaxForce(...)) and see that the arm will still fall, or not execute the velocites correctly, even with huge values.

BTW, I'm using ROS Hydro on Ubuntu 12.04.

2014-08-11 03:35:02 -0500 commented answer Joints Drift when they are not being driven or have a set velocity of zero

Hi Peter, I'm also having the same issue. I'm working with a robotic arm, trying to implement velocity controllers with velocity interface (effortcontrollers/JointVelocityController) using ROS and Gazebo. gazeboros_control internally uses Joint::SetVelocity in this case, but for some reason the model stays up for a minute and then falls. I'll try to check the inertias, but it's also weird that if I send a sine velocity profile, it can't keep up either. Could it be too because of the inertias?