ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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 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 The output of |
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? |
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 in arm_controller_ur10.yaml to however, when I launch my simulation the following appears. 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. where pid_for_gazebo_ros_control.yaml contains just the following. (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). 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? ===== 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 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 For this plot the gripper friction coefficient is changed to 100, which appears to have made no change. The final plot is with mu=100 and using the 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 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 Here is an animation and force plot when using Here is an animation and force plot when using 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 |
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 |