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

CMobley7's profile - activity

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

ur5_arm:
  kinematics_solver: ur_kinematics/UR5KinematicsPlugin
  kinematics_solver_search_resolution: 0.005
  kinematics_solver_timeout: 0.005
  kinematics_solver_attempts: 3

to

ur5_arm:
  kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin
  kinematics_solver_timeout: 0.05
  solve_type: Manipulation1

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:

# Give the node a name
rospy.init_node("drill_prediction", anonymous=False)
# Initialize the move_group API
moveit_commander.roscpp_initialize(sys.argv)
# Initialize the move group for the arm
ur5_arm = moveit_commander.MoveGroupCommander("ur5_arm")
# Get the name of the end-effector link
end_effector_link = ur5_arm.get_end_effector_link()
# Set the reference frame for pose targets
 reference_frame = "/base_link"
# Set the arm reference frame accordingly
ur5_arm.set_pose_reference_frame(reference_frame)
# Allow replanning to increase the odds of a solution
ur5_arm.allow_replanning(True)
# Allow some leeway in position (meters) and orientation (radians)
ur5_arm.set_goal_position_tolerance(0.01)
ur5_arm.set_goal_orientation_tolerance(0.05)
#Move the end effecor to the x , y, z positon
#Set the target pose in the base_link frame
target_pose = PoseStamped()
target_pose.header.frame_id = reference_frame
target_pose.header.stamp = rospy.Time.now()
target_pose.pose.position.x = 1.0 #hole_pose.position.x
target_pose.pose.position.y = .1 #hole_pose.position.y
target_pose.pose.position.z = .7 #hole_pose.position.z
target_pose.pose.orientation.x = 0 #hole_pose.orientation.x
target_pose.pose.orientation.y = 0 #hole_pose.orientation.y
target_pose.pose.orientation.z = 0 #hole_pose.orientation.z
target_pose.pose.orientation.w = 1 #hole_pose.orientation.w
# Set the start state to the current state
ur5_arm.set_start_state_to_current_state()
# Set the goal pose of the end effector to the stored pose
ur5_arm.set_pose_target(target_pose, end_effector_link)
# Plan the trajectory to the goal
traj = ur5_arm.plan()
# Execute the planned trajectory
ur5_arm.execute(traj)
# Pause for a second
rospy.sleep(1)
# Shut down MoveIt cleanly
moveit_commander.roscpp_shutdown()
# Exit MoveIt
moveit_commander.os._exit(0)

However, my nodes fails to set the params as I have set them in my kinematics.yaml

ur5_arm:
  kinematics_solver: trac_ik_kinematics_plugin/TRAC_IKKinematicsPlugin
  kinematics_solver_timeout: 0.05
  solve_type: Manipulation1

and returns this

[ INFO] [1467410538.629341568, 298.510000000]: Looking in private handle: /move_group_commander_wrappers_1467410538042921053 for param name: ur5_arm/position_only_ik
[ INFO] [1467410538.629825732, 298.510000000]: Looking in private handle: /move_group_commander_wrappers_1467410538042921053 for param name: ur5_arm/solve_type
[ INFO] [1467410538.630190163, 298.510000000]: Using solve type Speed

Despite my launch file below including every way I can think of to set these parameters.

    <launch>
      <!-- Load the URDF, SRDF and other .yaml configuration files on the param server -->
      <include file="$(find husky_ur5_moveit_config)/launch/planning_context.launch">
        <arg name="load_robot_description" value="true"/>
      </include>

      <node name="drill_predition" pkg="ccam_arm_nav" type="drill_prediction.py" output="screen">
        <rosparam command="load" file="$(find husky_ur5_moveit_config)/config/kinematics.yaml"/>
        <param name="arm_prefix" value="ur5_arm_"/> 
        <param name="move_group/ur5_arm/solve_type" value="Manipulation1"/>
        <param name="move_group/ur5_arm/kinematics_solver_timeout" value="0.05"/>
        <param name="ur5_arm/solve_type" value="Manipulation1"/>
        <param name="ur5_arm/kinematics_solver_timeout" value="0.05"/>
        <param name="solve_type" value="Manipulation1"/>
        <param name="kinematics_solver_timeout" value="0.05"/>
        <rosparam>
          move_group/ur5_arm/solve_type: 'Manipulation1'
          move_group/ur5_arm/kinematics_solver_timeout: 0.05
          ur5_arm/solve_type: 'Manipulation1'
          ur5_arm/kinematics_solver_timeout: 0.05
          solve_type: 'Manipulation1'
          kinematics_solver_timeout: 0.05
        </rosparam>
      </node>

    </launch>

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.

# Initialize the move group for the arm
ur5_arm = moveit_commander.MoveGroupCommander("ur5_arm")
# Get the name of the end-effector link
end_effector_link = ur5_arm.get_end_effector_link()
# Set the reference frame for pose targets
 reference_frame = "/base_link"
# Set the arm reference frame accordingly
ur5_arm.set_pose_reference_frame(reference_frame)
# Allow replanning to increase the odds of a solution
 ur5_arm.allow_replanning(True)
# Allow some leeway in position (meters) and orientation (radians)
ur5_arm.set_goal_position_tolerance(0.01)
ur5_arm.set_goal_orientation_tolerance(0.05)
#Move the end effecor to the x , y, z positon
#Set the target pose in the base_link frame
target_pose = PoseStamped()
target_pose.header.frame_id = reference_frame
target_pose.header.stamp = rospy.Time.now()
target_pose.pose.position.x = 1.0 #hole_pose.position.x
target_pose.pose.position.y = .1 #hole_pose.position.y
target_pose.pose.position.z = .7 #hole_pose.position.z
target_pose.pose.orientation.x = 0 #hole_pose.orientation.x
target_pose.pose.orientation.y = 0 #hole_pose.orientation.y
target_pose.pose.orientation.z = 0 #hole_pose.orientation.z
target_pose.pose.orientation.w = 1 #hole_pose.orientation.w
# Set the start state to the current state
ur5_arm.set_start_state_to_current_state()
# Set the goal pose of the end effector to the stored pose
ur5_arm.set_pose_target(target_pose, end_effector_link)
# Plan the trajectory to the goal
traj = ur5_arm.plan()
# Execute the planned trajectory
ur5_arm.execute(traj)
# Pause for a second
rospy.sleep(1)

However, the code gives the following errors:

[ERROR] [1467334302.962946004, 615.710000000]: Kin chain provided in model doesn't contain standard UR joint 'shoulder_lift_joint'.
[ERROR] [1467334302.963030369, 615.710000000]: Kinematics solver of type 'ur_kinematics/UR5KinematicsPlugin' could not be initialized for group 'ur5_arm'
[ERROR] [1467334302.963234727, 615.710000000]: Kinematics solver could not be instantiated for joint group ur5_arm.
[ INFO] [1467334303.757624243, 616.500000000]: Ready to take MoveGroup commands for group ur5_arm.
[ INFO] [1467334303.757756298, 616.500000000]: Replanning: yes
[ WARN] [1467334307.237704997, 619.980000000]: Fail: ABORTED: No motion plan found. No execution attempted.

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.

mkdir ws && cd ws
wstool init src https://raw.github.com/wg-perception/object_recognition_core/master/doc/source/ork.rosinstall
cd src && wstool update -j8
cd .. && rosdep install --from-paths src -i -y
catkin_make
source devel/setup.bash

However, when I catkin_make I get the following errors.

CMake Error at /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:75 (find_package):
  Could not find a package configuration file provided by "moveit_core" with
  any of the following names:

    moveit_coreConfig.cmake
    moveit_core-config.cmake

  Add the installation prefix of "moveit_core" to CMAKE_PREFIX_PATH or set
  "moveit_core_DIR" to a directory containing one of the above files.  If
  "moveit_core" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  ork_tabletop/CMakeLists.txt:4 (find_package)


CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GLUT_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src/apps

-- Configuring incomplete, errors occurred!
See also "/home/cmobley7/catkin_ws/ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/cmobley7/catkin_ws/ws/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed

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.

CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find GLUT (missing: GLUT_glut_LIBRARY GLUT_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-2.8/Modules/FindGLUT.cmake:82 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  moveit/perception/CMakeLists.txt:14 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/cmobley7/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/cmobley7/catkin_ws/build/CMakeFiles/CMakeError.log".
make: *** [cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed

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.

mkdir ws && cd ws
wstool init src https://raw.github.com/wg-perception/object_recognition_core/master/doc/source/ork.rosinstall
cd src && wstool update -j8
cd .. && rosdep install --from-paths src -i -y
catkin_make
source devel/setup.bash

I was able to resolve a number of errors, but I can't resolve the one include below.

CMake Error at /opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:75 (find_package):
  Could not find a package configuration file provided by "moveit_core" with
  any of the following names:

    moveit_coreConfig.cmake
    moveit_core-config.cmake

  Add the installation prefix of "moveit_core" to CMAKE_PREFIX_PATH or set
  "moveit_core_DIR" to a directory containing one of the above files.  If
  "moveit_core" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  ork_tabletop/CMakeLists.txt:4 (find_package)


CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GLUT_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src
   used as include directory in directory /home/cmobley7/catkin_ws/ws/src/ork_renderer/src/apps

-- Configuring incomplete, errors occurred!
See also "/home/cmobley7/catkin_ws/ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/cmobley7/catkin_ws/ws/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed

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.

CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find GLUT (missing: GLUT_glut_LIBRARY GLUT_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-2.8/Modules/FindGLUT.cmake:82 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  moveit/perception/CMakeLists.txt:14 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/cmobley7/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/cmobley7/catkin_ws/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed

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