ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

raequin's profile - activity

2021-06-17 03:48:12 -0500 received badge  Great Question (source)
2021-06-17 03:48:07 -0500 received badge  Good Answer (source)
2020-09-25 00:55:23 -0500 received badge  Great Answer (source)
2020-09-25 00:55:23 -0500 received badge  Guru (source)
2020-07-13 18:45:03 -0500 received badge  Favorite Question (source)
2020-03-20 05:19:43 -0500 received badge  Good Question (source)
2020-03-20 05:19:38 -0500 received badge  Nice Answer (source)
2020-02-13 11:51:13 -0500 marked best answer Trouble setting up computer with ROS Kinetic, Gazebo 9, and latest gazebo_ros_pkgs

Setting up a computer to use ROS kinetic, Gazebo 9, and the latest version of gazebo_ros_pkgs (from source) is giving errors. They are basically controller type 'fu/bar' not exist.

[ INFO] [1524592104.175529525, 0.137000000]: Loading gazebo_ros_control plugin
[ INFO] [1524592104.175757532, 0.137000000]: Starting gazebo_ros_control plugin in namespace: /
[ INFO] [1524592104.176666268, 0.137000000]: gazebo_ros_control plugin is waiting for model URDF in parameter [robot_description] on the ROS param server.
[ INFO] [1524592104.309520405, 0.137000000]: Loaded gazebo_ros_control.
[ INFO] [1524592104.331149974, 0.159000000]: waitForService: Service [/gazebo/set_physics_properties] is now available.
Loaded joint_state_controller
[ERROR] [1524592104.335562797, 0.163000000]: Could not load controller 'arm_controller' because controller type 'position_controllers/JointTrajectoryController' does not exist.
[ERROR] [1524592104.335600886, 0.163000000]: Use 'rosservice call controller_manager/list_controller_types' to get the available types
Error when loading arm_controller
[ERROR] [1524592104.339144617, 0.167000000]: Could not load controller 'gripper_fake_controller' because controller type 'effort_controllers/JointPositionController' does not exist.
[ERROR] [1524592104.339186543, 0.167000000]: Use 'rosservice call controller_manager/list_controller_types' to get the available types
Error when loading gripper_fake_controller
[ERROR] [1524592104.343053113, 0.171000000]: Could not load controller 'mobile_base_fake_controller' because controller type 'effort_controllers/JointPositionController' does not exist.
[ERROR] [1524592104.343081991, 0.171000000]: Use 'rosservice call controller_manager/list_controller_types' to get the available types
Error when loading mobile_base_fake_controller
Started ['joint_state_controller'] successfully
[ERROR] [1524592104.349697714, 0.177000000]: Could not start controller with name arm_controller because no controller with this name exists
Error when starting  ['arm_controller']
[ERROR] [1524592104.352091520, 0.180000000]: Could not start controller with name gripper_fake_controller because no controller with this name exists
Error when starting  ['gripper_fake_controller']
[ERROR] [1524592104.354369094, 0.183000000]: Could not start controller with name mobile_base_fake_controller because no controller with this name exists
Error when starting  ['mobile_base_fake_controller']

Based on this answer, I set up the new computer as follows

Thanks for looking at this. Please let me know if you have any suggestions.

Edit: Running sudo apt install ros-kinetic-position-controllers and sudo apt install ros-kinetic-effort-controllers helped with most of the errors but I am still left with

[ERROR] [1524614845.792391368, 0.313000000]: Could not load controller 'arm_controller' because controller type 'position_controllers/JointTrajectoryController' does not exist.
[ERROR] [1524614845.792423207, 0.313000000]: Use 'rosservice call controller_manager/list_controller_types' to get the available types

The output of rosservice call controller_manager/list_controller_types is

types: [effort_controllers/JointEffortController, effort_controllers/JointGroupEffortController, effort_controllers/JointGroupPositionController, effort_controllers/JointPositionController, effort_controllers/JointVelocityController, joint_state_controller/JointStateController, position_controllers/JointGroupPositionController, position_controllers/JointPositionController]
base_classes: ['controller_interface::ControllerBase', 'controller_interface::ControllerBase', 'controller_interface::ControllerBase', 'controller_interface::ControllerBase', 'controller_interface::ControllerBase', 'controller_interface::ControllerBase', 'controller_interface::ControllerBase', 'controller_interface::ControllerBase']
2020-02-13 11:51:13 -0500 received badge  Self-Learner (source)
2019-12-01 12:44:35 -0500 received badge  Good Answer (source)
2019-11-14 09:14:47 -0500 received badge  Famous Question (source)
2019-09-13 16:50:07 -0500 marked best answer rviz keeps displaying initial pose

When I use rviz, the initial state of the robot persists throughout the entire session. In the picture below, the robot started stretched out parallel to the ground then moved up into the higher pose. Everything in rviz seems to work fine but it would be nice to (a) know what's causing this artifact, and (b) not have that pose cluttering the view. Can you help me?

image description

2019-06-16 17:53:26 -0500 received badge  Nice Answer (source)
2019-05-24 03:42:31 -0500 received badge  Nice Question (source)
2019-04-02 12:59:12 -0500 received badge  Nice Question (source)
2019-03-21 04:29:06 -0500 marked best answer Mobile arm simulation behaves strangely when adding ros_control plugin for arm

Greetings. My model combining a simple mobile base with the UR10 acts strangely when I add

<plugin name="ros_control" filename="libgazebo_ros_control.so"/>

which is needed for controlling the UR10 joints. The strange behavior is that the mobile robot resists motion (or maybe it's just the mobile base that does this). Two examples:

(1) If I publish a large velocity twist to the cmd_vel topic for the differential_drive_controller on the mobile base the two wheels spin quickly but the robot rotates only very slowly.

(2) If I publish a positive z-position to set_model_state, effectively dropping the robot from this height, it falls very slowly to the ground.

The "real time factor" is 1.00 so it's not as if the simulation is running slowly when the plugin is added. When I don't add the plugin the robot arm is floppy but it moves quickly, as one would expect (the base moves it around at the desired rate and it falls as fast as normal). The differential_drive_controller seems to be working fine and so does the arm_controller it's just that when I'm using the arm_controller the sim acts crazy. If I remove the diff-drive controller but keep arm_controller the weird behavior remains.

I will look through the husky simulator with UR5 enabled to try to find what is wrong with my robot.

When publishing an arm pose to arm_controller/command the manipulator moves at a reasonable speed relative to its base but the overall mobile robot is still very slow. For example, if I drop it from two meters and publish a manipulator pose the arm moves fine but the entire robot falls very slowly.

For reference, here is the source (except for ur10.urdf.xacro). The offending gazebo plugin tag is found in models/common.gazebo.xacro.

One other note: this question is also posted to answers.gazebosim.org . Is it frowned-upon behavior to post at both these sites?

*edit: First off, thanks for the information in the accepted answer. My inital attempt to resolve this was to replace PositionJointInterface in ur.transmission.xacro with VelocityJointInterface. This required changing

type: position_controllers/JointTrajectoryController

in arm_controller_ur10.yaml to

type: velocity_controllers/JointTrajectoryController

however, when I launch my simulation the following appears.

[ERROR] [1520431422.716199942, 0.480000000]: No p gain specified for pid.  Namespace: /arm_controller/gains/shoulder_pan_joint

Since I don't know how to specify gains for that controller, I tried another option you describe. For my second attempt, I reverted to the original configuration (PositionJointInterface with position_cotrollers) and added this line to my launch file.

  <rosparam file="$(find mobile_arm)/models/my_ur10/pid_for_gazebo_ros_control.yaml" command="load"/>

where pid_for_gazebo_ros_control.yaml contains just the following.

gazebo_ros_control:
  pid_gains:
    shoulder_pan_joint: {p: 100.0, i: 0.01, d: 10.0}
    shoulder_lift_joint: {p: 100.0, i: 0.01, d: 10.0}
    elbow_joint: {p: 100.0, i: 0.01, d: 10.0}
    wrist_1_joint: {p: 100.0, i: 0.01, d: 10.0}
    wrist_2_joint: {p: 100.0, i: 0.01, d: 10.0}
    wrist_3_joint: {p: 100.0, i ...
(more)
2019-03-20 15:51:13 -0500 commented question Got controller gains for six-axis manipulator?

The values at the link in the accepted answer worked well. linear_arm_actuator_joint: {p: 10000, d: 500, i: 0, i_clamp:

2019-03-20 07:02:12 -0500 received badge  Notable Question (source)
2019-02-28 08:44:20 -0500 received badge  Famous Question (source)
2018-11-08 07:59:00 -0500 received badge  Necromancer (source)
2018-10-29 13:58:43 -0500 received badge  Famous Question (source)
2018-09-24 08:47:11 -0500 commented answer Got controller gains for six-axis manipulator?

The first time I used the posted gains was with a voluminous tool on the robot and the manipulator had a lot of overshoo

2018-09-22 13:28:44 -0500 received badge  Popular Question (source)
2018-09-19 08:12:30 -0500 received badge  Necromancer (source)
2018-09-19 08:12:30 -0500 received badge  Self-Learner (source)
2018-09-19 05:11:45 -0500 received badge  Notable Question (source)
2018-09-17 14:02:13 -0500 marked best answer Simple box grasping fails

Grasping is not working in this primitive case I've made. The object is a box of mass 1 and default friction and contact parameters. The gripper uses two prismatic joints to move two c-shaped links together. All these are shown in this image. Note the gripper-joint coordinate frames (the x- and z-direction vectors are visible).

image description

When the gripper closes on the box and the robot then moves upward, the box does not get lifted, as shown in this animation (it's for a taller gripper than above but the behavior is identical, also the gripper in the animation used just one prismatic joint). Since the normal force between the gripper and box is 200 N (that's what I have the joint effort set at, as shown in the sdf below) then the lifting force should be at least 200 N, while 9.81 N should suffice to lift the box. Do you have an idea why the box doesn't go up?

image description

===== additional info Here's a link to my gazebosim question on the same topic with a slightly different grasping scenario. http://answers.gazebosim.org/question... =====

The following plots were made via

rqt_plot ft_senr_topic_p/wrench/force/x, ft_sensor_topic_p/wrench/force/z, ft_sensor_topic_d/wrench/force/x, ft_sensor_topic_d/wrench/force/z

to graph the x and z components of the joint forces for the two prismatic gripper joints. In this one the joints are controlled with the EffortJointInterface. When the x components drop down, at about 28.6 seconds, that's when the gripper is higher than the box and it closes.

image description

For this plot the gripper friction coefficient is changed to 100, which appears to have made no change.

image description

The final plot is with mu=100 and using the PositionJointInterface. At about 24.4 seconds On this one, the x-components drop down. That's when the robot starts to move upward (prior to that it's stationary with the gripper closed around the box). The spikes after that, at 24.8, are when the gripper clears the box. It's odd to me that one joint has a positive z-component and the other has a negative z-component of force.

image description

Update

In an attempt to circumvent this problem I made an object that's wider in the middle and gripper blocks to match it. In theory, if the gripper stayed at its closed position then friction would not be required for lifting the object. I increased the effort limit on the joints from 200 to 500.

With 'EffortJointInterface' the same problem occurs as with the box, and with the PositionJointInterface the grasp is unstable and the object goes flying away.

To battle the instability I changed max_vel and min_depth on both the gripper and object to 0 and 0.001, respectively. Alas, the simulation remained unstable with PositionJointInterface even with these changes.

Here is an animation and force plot when using EffortJointInterface.

image description

image description

Here is an animation and force plot when using PositionJointInterface.

image description

image description

Here is the sdf of the object ... (more)

2018-09-17 14:01:19 -0500 answered a question Simple box grasping fails

The cause behind this unrealistic interaction (that is, this lack of friction) is the use of PositionJointInterface for

2018-09-17 08:31:13 -0500 commented answer Got controller gains for six-axis manipulator?

Those values perform better for me than the original ones in the link included in the question. The ones you referred t

2018-09-17 08:30:59 -0500 commented answer Got controller gains for six-axis manipulator?

Those values perform better for me than the original ones in the link above. The ones you referred to are a good starti

2018-09-17 08:30:07 -0500 marked best answer Got controller gains for six-axis manipulator?

Do you have working PID gains for the effort_controllers/JointTrajectoryController of a six-axis manipulator that I could use as a starting point for tuning the gains on a UR10? The universal_robot package uses the PositionJointInterface class for getting the joints to their desired positions but this mechanism causes unrealistic interactions between the manipulator and the Gazebo environment. For that reason I've changed the package locally to use the EffortJointInterface following this example. The author notes that the gains there are not working. Please share with me any advice on tuning a 6-R 'bot or working gains for a manipulator.

2018-09-16 20:50:50 -0500 asked a question Got controller gains for six-axis manipulator?

Got controller gains for six-axis manipulator? Do you have working PID gains for the effort_controllers/JointTrajectoryC

2018-09-14 16:23:00 -0500 commented answer rviz keeps displaying initial pose

Thanks! Following those modifications allowed me to see that using PositionJointInterface is the source for the unreali

2018-09-14 12:22:18 -0500 commented answer rviz keeps displaying initial pose

PS --- Do you know why this tutorial (http://gazebosim.org/tutorials/?tut=ros_control) states that "the <hardwareInte

2018-09-14 12:21:34 -0500 commented answer rviz keeps displaying initial pose

Cool. If you have a minute, I'd appreciate pointers on changing that. I figure it will include replacing PositionJoint