ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2023-07-28 16:31:11 -0500 | received badge | ● Taxonomist |
2020-07-20 12:31:51 -0500 | received badge | ● Favorite Question (source) |
2020-02-05 14:35:53 -0500 | received badge | ● Self-Learner (source) |
2020-02-05 14:35:53 -0500 | received badge | ● Teacher (source) |
2017-11-22 11:04:50 -0500 | received badge | ● Famous Question (source) |
2017-03-28 09:00:14 -0500 | received badge | ● Famous Question (source) |
2016-10-03 18:48:39 -0500 | received badge | ● Famous Question (source) |
2016-08-24 10:14:54 -0500 | received badge | ● Notable Question (source) |
2016-07-29 16:06:06 -0500 | received badge | ● Scholar (source) |
2016-07-08 08:42:06 -0500 | received badge | ● Popular Question (source) |
2016-07-03 10:01:07 -0500 | received badge | ● Notable Question (source) |
2016-07-02 09:47:38 -0500 | received badge | ● Notable Question (source) |
2016-07-01 21:53:31 -0500 | received badge | ● Popular Question (source) |
2016-07-01 18:53:50 -0500 | answered a question | UR5KinematicsPlugin fails to plan in Cartesian space on Clearpath Husky equipped with UR5 I installed trac-ik-kinematics-plugin and changed my kinematics.yaml file from to This fixed both the prefix error and has successfully solved every IK problem I have given it. So, the issue may lie in the planner. |
2016-07-01 18:50:58 -0500 | asked a question | Unable to set solver_type in launch file via kinematics.yaml or param/rosparam for trac_ik To Whom It May Concern, After installing trac-ik-kinematics-plugin, I changed the kinematics.yaml to use trac_ik vs ur_kinematics and my Clearpath Husky with UR5 arm successfully planned several IK problems. However, when I use the code below: However, my nodes fails to set the params as I have set them in my kinematics.yaml and returns this Despite my launch file below including every way I can think of to set these parameters. However, move_group.launch and moveit_rviz.launch seem to set them correctly. Accuracy rather than speed is my desire; so, I like to test out the other solver_types, such as Manipulation1 ... (more) |
2016-07-01 11:14:38 -0500 | commented answer | UR5 zero position and ROS zero position different I should have this clarified above. The UR5 worked correctly after resizing the partition. However, the husky_base no longer had comm with ROS. Clearpath support was able to solve this issue; however, after which the UR5 no longer had comm with ROS. The issue above surfaced after comm was restored. |
2016-07-01 01:59:41 -0500 | received badge | ● Popular Question (source) |
2016-06-30 21:02:57 -0500 | answered a question | UR5 zero position and ROS zero position different To Whom It May Concern, Adjusting the arm 90 degrees solved the issue. Very Respectfully, CMobley7 |
2016-06-30 20:57:01 -0500 | asked a question | UR5KinematicsPlugin fails to plan in Cartesian space on Clearpath Husky equipped with UR5 To Whom It May Concern, I ran across the following ros-industrial ticket in trying to solve the inverse kinematic issue I am having. https://github.com/ros-industrial/uni... https://github.com/ros-industrial/uni... https://github.com/ros-industrial/uni... https://github.com/ros-industrial/uni... https://github.com/ros-industrial/uni... The response to these tickets was to rewrite portions of ur_kimematic/UR5KinematicsPlugin to allow the ur5_arm to better plan and execute. However, the main topic was RVIZ. RVIZ to the best of my knowledge is using forward kinematics due to the fact it already knows the ending joint angles. I attempted to perform inverse kinematic planning using Moveit!’s Python interface with the code below on a Clearpath Husky equiped with a UR5. However, the code gives the following errors: The prefix errors do not seem to affect the planner in solving forward kinematic motion problem. As I have used similar code to go to group states set in the srdf, as well as other random valid joint configurations. However, when specifying a Cartesian point, the planner always fails. After reading the posts regarding ur_kimematic/UR5KinematicsPlugin, I think the problem is more likely that my code is not using the same configuration in regards to using limited joint angles when planning and not setting ... (more) |
2016-06-21 12:19:35 -0500 | asked a question | UR5 zero position and ROS zero position different To Whom It May Concern, After updating partition sizes on the hard drive used by my Lab's Clearpath Husky equipped with a Universal Robots UR5, ROS continues to communicates accurately with the arm. However, the ROS zero position for the ur5_arm_shoulder_pan_joint is 90 degree, pi/4, different on the physical arm. The tool0_controller, created by ur_modern_driver, shows the accurate position of the end effector. However, the physical links themselves are off. As a result, when I send the UR5 to specified positions, the arm ends up in the wrong position because the ur5_arm_shoulder_pan_joint is off 90 degrees. I've looked into the husky_ur5_moveit_config, https://github.com/husky/husky/tree/i... , and ur_modern_driver, https://github.com/ThomasTimm/ur_mode... , but haven't found anything that could cause this issue. The only solution I've thought of yet is physically bolting the arm 90 degrees different from its current position; so that, ROS and the UR5 arm agree on their position. However, this isn't ideal. Thank you for taking the time to read this post, as well as any help you are able to give. Have a great week. God bless. Very Respectfully, CMobley7 |
2016-04-14 16:14:13 -0500 | answered a question | rossrv - cannot deserialize custom msg I'm having similar a similar issue. Did you ever figure this out? |
2016-02-10 13:15:00 -0500 | answered a question | -- Configuring incomplete, errors occurred! Asaad Irfan, Thanks for the reply. In my case, this error appeared to be caused by a missing or corrupted file in catkin. So, instead of uninstalling ROS completely, we removed and reinstall catkin. After which, everything worked as expected. Very Respectfully, CMobley7 |
2016-02-03 09:55:50 -0500 | answered a question | Implementing GMapping with Two Lidars First, I suggest ensuring that the LIDARS are accurately centered on both the robot and in the URDF. While the URDF showed our LIDARS were centered, they were slightly off on the actually robot. Due to how we affixed the LIDARS to the robot, it was easier for use to fine-tune the placement of the LIDARS sensors in the URDF. The LaserScan data from each LIDAR was shown in RVIZ, each in a different color. We performed multiple iterations of placing an object at different distances and slightly modifying each LIDARS position in the URDF until they agreed as to the placement of the object. However, this could easily be done the other way around, slightly adjusting the placement of the LIDAR sensor on the robot until they agree. This was successful in removing most of the false data. So, depending on your application this may be the optimal solution. In addition, I suggest using many of the filters in laser_filter to filter the raw LaserScan data to ensure your are giving quality data to GMapping. Another option would be to use the laser_filter package to limit the range of the Sick LMS151 sensor to 180 degrees and add another sensor for front-facing FOV. This last option was what we choose to implement, due to the fact that the LIDARs would not have more than 180 degree FOV in our final application. |
2016-01-21 13:17:12 -0500 | answered a question | -- Configuring incomplete, errors occurred! Asaad Irfan, I am actually receiving the same error. Did you ever resolve it? Thank you for any help you are able to give, as well as your time and attention to this matter. Have a great rest of the week. Very Respectfully, CMobley7 |
2015-08-03 09:07:32 -0500 | received badge | ● Famous Question (source) |
2015-07-04 13:38:56 -0500 | received badge | ● Notable Question (source) |
2015-06-25 01:55:55 -0500 | received badge | ● Popular Question (source) |
2015-06-24 14:43:30 -0500 | asked a question | Implementing GMapping with Two Lidars So, I am attempting to autonomously navigate a Clearpath Robotics' Husky using GMapping. The Husky is currently equipped with two Sick LMS151 lidars, one centered on both the left and right side. Presently, the laser data from the two Sick LMS151 lidars is being merged together using the ira_laser_merger package available at https://github.com/iralabdisco/ira_la... . Unfortunately, while this package does merge the laser data, it does so in a way that creates false data at different points around the Husky. As an example, when I stand in front of the Husky and move backwards, it shows this. However, it also shows me moving toward the back of the Husky. Is there a way to fix this problem using the packages I am currently using or is there a better method I can implement for using two lidars with GMapping? |
2015-02-26 12:13:17 -0500 | answered a question | GPS INS navigation Fatiba, Any luck on finding applicable packages. Very Respectfully, Chris |
2014-12-30 06:36:14 -0500 | received badge | ● Famous Question (source) |
2014-11-26 15:53:48 -0500 | received badge | ● Popular Question (source) |
2014-11-26 15:53:48 -0500 | received badge | ● Notable Question (source) |
2014-10-31 15:59:43 -0500 | asked a question | Object Recognition Kitchen CMake Fail To Whom It May Concern, As an FYI, I am running Ubuntu 14.04 with ROS Indigo. Also, I am fairly new to ROS. I am trying to install the Object Recognition Kitchen using the commands below. However, when I catkin_make I get the following errors. I have tried to fix these particular error in two ways. 1) I downloaded moveit from https://github.com/ros-planning/movei... . However, when I make it. I get the following errors. 2) I installed moveit_core, which failed and wanted moveit_msgs, which failed and wanted octomap, which failed because it called for metadata "ros". Any help you can provide would be greatly appreciated. Very Respectfully, Christopher |
2014-10-31 15:49:14 -0500 | asked a question | Object Recognition Kitchen CMake Fail To Whom It May Concern, As an FYI, I am using ROS Indigo and Ubuntu 14.04. Also, I am fairly new to ROS. I am trying to install the object recognition kitchen using the commandas included below. I was able to resolve a number of errors, but I can't resolve the one include below. I have tried to fix this in two way. 1) I downloaded moveit from https://github.com/ros-planning/movei... and attempted to make it. This resulted in the error below. 2) I downloaded the moveit_core package and tried to make it, it wanted moveit_msgs, which wanted octomap which depended on metadata "ros" which is outdated. Any help you could give would be greatly appreciated. Very Respectfully, Chris |