Quantcast
Channel: ROS Answers: Open Source Q&A Forum - RSS feed
Viewing all 1441 articles
Browse latest View live
↧

Correct implementation of ComputeCartesianPath to move end actuator in a straight line?

July 23, 2018, 7:12 am
$
0
0
Hello everyone. I'm quite new to ROS, doing a practicum project right now and have been pretty stumped with this for a few days. I have a TIAGo Robot, with a 6DOF arm with whom I want to be able to move on a straight line. The "straight" part is important as we'll be having a pressure sensor on the fingertip with which we want to do "feeling" of surfaces, so we need to be able to move it on a straight line (maintaining orientation of it) on the XY plane. So I've been basically doing some frankencode because while I'm familiar with C++, I'm not with ROS and MoveIt!; and been piecing something together from a basic code in the [TIAGo tutorials](http://wiki.ros.org/Robots/TIAGo/Tutorials/MoveIt/Planning_cartesian_space) that moves the actuator to a cartesian point and orientation (but not necessarily in a straight line) and the [moveit tutorial](http://docs.ros.org/indigo/api/moveit_tutorials/html/doc/pr2_tutorials/planning/src/doc/move_group_interface_tutorial.html#cartesian-paths) that deals with Cartesian path. Current code: /* * Software License Agreement (Modified BSD License) * * Copyright (c) 2016, PAL Robotics, S.L. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above * copyright notice, this list of conditions and the following * disclaimer in the documentation and/or other materials provided * with the distribution. * * Neither the name of PAL Robotics, S.L. nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. */ /** \author Jordi Pages. */ // ROS headers #include #include "shape_msgs/SolidPrimitive.h" #include "moveit_msgs/BoundingVolume.h" // MoveIt! headers #include //#include // Std C++ headers #include #include #include #include int main(int argc, char** argv) { ros::init(argc, argv, "plan_arm_torso_ik_idril"); if ( argc < 7 ) { ROS_INFO(" "); ROS_INFO("\tUsage:"); ROS_INFO(" "); ROS_INFO("\trosrun tiago_moveit_tutorial plan_arm_torso_ik_idril x y z r p y"); ROS_INFO(" "); ROS_INFO("\twhere the list of arguments specify the target pose of /arm_tool_link expressed in /base_footprint"); ROS_INFO(" "); return EXIT_FAILURE; } geometry_msgs::PoseStamped goal_pose; goal_pose.header.frame_id = "base_footprint"; goal_pose.pose.position.x = atof(argv[1]); goal_pose.pose.position.y = atof(argv[2]); goal_pose.pose.position.z = atof(argv[3]); goal_pose.pose.orientation = tf::createQuaternionMsgFromRollPitchYaw(atof(argv[4]), atof(argv[5]), atof(argv[6])); ros::NodeHandle nh; ros::AsyncSpinner spinner(1); spinner.start(); std::vector torso_arm_joint_names; //select group of joints moveit::planning_interface::MoveGroupInterface group_arm_torso("arm_torso"); const robot_state::JointModelGroup* joint_model_group = group_arm_torso.getCurrentState()->getJointModelGroup("arm_torso"); //choose your preferred planner group_arm_torso.setPlannerId("SBLkConfigDefault"); group_arm_torso.setPoseReferenceFrame("base_footprint"); group_arm_torso.setPoseTarget(goal_pose); ROS_INFO_STREAM("Planning to move" << group_arm_torso.getEndEffectorLink() << " to a target pose expressed in " << group_arm_torso.getPlanningFrame()); group_arm_torso.setStartStateToCurrentState(); group_arm_torso.setMaxVelocityScalingFactor(1.0); // Getting Basic Information // ^^^^^^^^^^^^^^^^^^^^^^^^^ // // We can print the name of the reference frame for this robot. ROS_INFO_NAMED("tutorial", "Reference frame: %s", group_arm_torso.getPlanningFrame().c_str()); // We can also print the name of the end-effector link for this group. ROS_INFO_NAMED("tutorial", "End effector link: %s", group_arm_torso.getEndEffectorLink().c_str()); // Planning with Path Constraints // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ // // Path constraints can easily be specified for a link on the robot. straight line // Let's specify a path constraint and a pose goal for our group. // First define the path constraint. ROS_INFO_STREAM("Calculating Restrictions"); geometry_msgs::PoseStamped start_pose; start_pose.header.frame_id = "base_footprint"; start_pose.pose = group_arm_torso.getCurrentPose().pose; geometry_msgs::PoseStamped vector_direccional; vector_direccional.pose.position.x = goal_pose.pose.position.x - start_pose.pose.position.x; vector_direccional.pose.position.y = goal_pose.pose.position.y - start_pose.pose.position.y; vector_direccional.pose.position.z = goal_pose.pose.position.z - start_pose.pose.position.z; double dist = sqrt(pow(vector_direccional.pose.position.x,2) + pow(vector_direccional.pose.position.y, 2) + pow(vector_direccional.pose.position.z,2)); ROS_INFO_STREAM("Calculated directional vector: " << vector_direccional.pose.position << "Start and goal points are at distance: " << dist); moveit_msgs::OrientationConstraint ocm; ocm.link_name = "arm_tool_link"; ocm.header.frame_id = "base_footprint"; ocm.orientation = group_arm_torso.getCurrentPose().pose.orientation; ocm.absolute_x_axis_tolerance = 0.1; ocm.absolute_y_axis_tolerance = 0.1; ocm.absolute_z_axis_tolerance = 0.1; ocm.weight = 1.0; ROS_INFO_STREAM("Calculated Orientation Constraint"); moveit_msgs::Constraints test_constraints; test_constraints.orientation_constraints.push_back(ocm); group_arm_torso.setPathConstraints(test_constraints); ROS_INFO_STREAM("Constraints set"); //Cartesian Path std::vector waypoints; waypoints.push_back(start_pose); waypoints.push_back(goal_pose); } moveit_msgs::RobotTrajectory trajectory; const double jump_threshold = 100; const double eef_step = dist; double fraction = 0; double old_jump_threshold = jump_threshold; double old_eef_step = eef_step; double good_jump_threshold = jump_threshold; double good_eef_step = eef_step; double good_fraction = fraction; //This loop is only to check how eef_step and jump_treshold affect the outcome. for(int i = 1; i <= 300; ++i){ for(int j = 1; j <= 1000; ++j){ fraction = group_arm_torso.computeCartesianPath(waypoints, eef_step/i, jump_threshold/j, trajectory, true); if (fraction < 0.15) break; if (fraction > good_fraction){ ROS_INFO_STREAM("Found better parameters: " << good_fraction* 100.0 << '%' << " ==> " << fraction * 100.0 << '%' << ":"); ROS_INFO_STREAM("eef " << old_eef_step << " ==> " << good_eef_step); ROS_INFO_STREAM("jump " << old_jump_threshold << " ==> " << good_jump_threshold); good_fraction = fraction; old_eef_step = good_eef_step; old_jump_threshold = good_jump_threshold; good_eef_step = eef_step/i; good_jump_threshold = jump_threshold/j; } if (fraction == 1) break; } if (fraction == 1) break; } if (fraction == 1) ROS_INFO_NAMED("tutorial", "Visualizing plan 4 (Cartesian path) (%.2f%% achieved)", fraction * 100.0); else{ fraction = group_arm_torso.computeCartesianPath(waypoints, good_eef_step, good_jump_threshold, trajectory, true); ROS_INFO_NAMED("tutorial", "Best I could do was (%.2f%% achieved)", fraction * 100.0); ROS_INFO_STREAM("With eef = " << good_eef_step << ", jump = " << good_jump_threshold); } moveit::planning_interface::MoveGroupInterface::Plan my_plan; //set maximum time to find a plan ROS_INFO_STREAM("Finding Plan..."); group_arm_torso.setPlanningTime(20.0); bool success = bool(group_arm_torso.plan(my_plan)); if ( !success ) throw std::runtime_error("No plan found"); ROS_INFO_STREAM("Plan found in " << my_plan.planning_time_ << " seconds"); // Execute the plan ros::Time start = ros::Time::now(); moveit::planning_interface::MoveItErrorCode e = group_arm_torso.move(); if (!bool(e)) throw std::runtime_error("Error executing plan"); ROS_INFO_STREAM("Motion duration: " << (ros::Time::now() - start).toSec()); group_arm_torso.clearPathConstraints(); spinner.stop(); return EXIT_SUCCESS; } I realise that it's probably just a newbie error somewhere but I've been scouring the forums about the ComputeCartesianPath() function and I don't really get how it works. Sometimes it returns 100% but the path comes out clearly curved, other times it's 0% but the path is visually straight. To add to this, is there a way to "compare" the outcome of the planned (executed) path to the "perfect" path? To make sure it's actually straight and have a number that gives me the error. Thank you very much for your help
↧
Search

Traffic planning in rviz and execution in Gazebo problem

July 23, 2018, 7:56 am
$
0
0
Using the moveit package I wanted to create a controller controlling my own hand using .py scripts. In my model I already have a controller, thanks to which I can move my hand with rqt_gui, but I wanted to go a step further. I did everything as in the movie https://youtu.be/j6bBxfD_bYs. The problem appeared at this moment https://youtu.be/rfcXZcKZd8A?t=922. On my rostopic list do not appear topics ... / goal, ... / result etc. I know the problem is in the controller, but I do not know how to solve it because I'm a beginner. I post a few ss. https://ibb.co/iPwV8d https://ibb.co/g2qMOd https://ibb.co/kbFkGy https://ibb.co/gzSqGy https://ibb.co/bROaid https://ibb.co/nJUCEJ https://ibb.co/eeCood https://ibb.co/hfk8od https://ibb.co/hQRsEJ
↧
↧

MoveIt! execution of joint group trajectories with "all joints controller"

July 6, 2018, 2:43 am
$
0
0
I have a robot with a couple of joint groups configured. The controller, however, serves a JointTrajectoryAction for the whole robot (there are no individual controllers for each joint group). My question now is: Is there a simple way for converting a trajectory that has been planned for a joint group to a trajectory for the whole robot, containing all joints? The resulting trajectory should just keep all joints that are not part of the planning group fixed. I know I can easily program that myself but it seems to me that this is a useful feature and might be implemented somewhere.
↧

Different Ways to Implement Custom Planners with MoveIt!

July 23, 2018, 8:15 pm
$
0
0
Hello! I am currently in the process of implementing a custom planner for my robot arm through MoveIt!. Looking at the documentation and at various forums, there seems to be two approaches. 1. Install OMPL from source and add your custom planner to OMPL. Then change the corresponding MoveIt! OMPL package to recognize this new planner. [[1]](https://web.archive.org/web/20141025194602/http://moveit.ros.org/wiki/OMPL/Add_New_Planner) [[2]](https://answers.ros.org/question/296238/custom-state-sampler-in-moveit/) [[3]](https://ompl.kavrakilab.org/newPlanner.html) [[4]](https://groups.google.com/forum/#!topic/moveit-users/Hm0Ah-ABeKI) 2. Use the motion planning plugin to directly add a planner to MoveIt! [[5]](https://moveit.ros.org/documentation/concepts/) [[6]](http://wiki.ros.org/industrial_trajectory_filters/Tutorials/PlanningRequestAdapterTutorial) My questions about implementing these custom planners are: 1. What are the pros and cons of each approach? Is there any advantage for using OMPL over directly implementing the planner into MoveIt! via a plugin? 2. Is there any additional tutorial/documentation for the second approach, implementing a planner plugin? It seems to me that the few sources/tutorials about implementing custom planners refer to the OMPL approach. Am I missing other tutorials about creating MoveIt! planning plugins? 3. Are there alternative approaches that I may have missed? Thank you for taking the time to read and respond. ###Sources [1] https://web.archive.org/web/20141025194602/http://moveit.ros.org/wiki/OMPL/Add_New_Planner [2] https://answers.ros.org/question/296238/custom-state-sampler-in-moveit/ [3] https://ompl.kavrakilab.org/newPlanner.html [4] https://groups.google.com/forum/#!topic/moveit-users/Hm0Ah-ABeKI [5] https://moveit.ros.org/documentation/concepts/ [6] http://wiki.ros.org/industrial_trajectory_filters/Tutorials/PlanningRequestAdapterTutorial
↧

How do I interact the actual robot with visualization by rviz in Moveit?

July 24, 2018, 8:06 pm
$
0
0
I have visualized my robot arm in Rviz. And the actual robot side also connects to RaspberryPi 3 (ROS installed already). I have read many documents and articles but they made me dizzy. As what I have researched that I have to create a publisher(in Moveit?) then send data to ActionServer (is this I have to setup on Raspberry Pi?), then using Ros in Raspberry to control servo? Is this plan correct? I am sorry if I make confusing, please help me to fix the plan for interacting with the actual robot!
↧
↧

Pick and Place using Moveit

July 25, 2018, 6:19 am
$
0
0
I am attempting to do a pick and place using a custom robot. I am using these scripts as my reference: https://github.com/DebasmitaGhose/moveit_tutorials/tree/kinetic-devel/doc/pick_place https://github.com/ros-planning/moveit_tutorials/blob/indigo-devel/doc/pr2_tutorials/pick_place/src/pick_place_tutorial.cpp I plan to use 2 hands with 2 end effectors to grasp a big object. So, how do I specify the reference frame for the pre grasp approach and the post grasp retreat? Also, how do I specify the position of the end effector for pick and place, since the two hands are at two different coordinates with respect to the robot.
↧

Moveit gdb debugging

June 15, 2018, 2:58 pm
$
0
0
Hi, I'm trying to run move_group code through gdb. I compiled moveit from sources with --cmake-args -DCMAKE_BUILD_TYPE=Debug. Still, it seems like debug information haven't been lost. What I did: I ran my own node that uses move_group.plan(my_plan) and tried to step through plan(). But it doesn't step into the function like it hadn't written debugging data. I use ros kinetic Would use any help. Thanks
↧

Help with cob_trajectory_controller

July 26, 2018, 1:42 pm
$
0
0
Hello, I am working with cob_trajectory_controller and MoveIt!. Currently I can generate and plan a new trajectory in MoveIt and upon trying to execute the trajectory the cob_controller fails everytime with a out_of_range error. Here is the error from the cob_trajectory_controller: core service [/rosout] found process[arm_controller/joint_trajectory_controller-1]: started with pid [27186] [ INFO] [1532628301.414878883]: getting JointNames from parameter server: //arm_controller [ INFO] [1532628301.420821815]: starting controller with DOF: 7 PTPvel: 0.400000 PTPAcc: 0.200000 maxError 0.150000 [ INFO] [1532628301.427403982]: Setting controller frequency to 100.000000 HZ [ INFO] [1532628416.297625889]: Received new goal trajectory with 20 points [ INFO] [1532628416.317896242]: Calculated 21 zwischenPunkte [ INFO] [1532628416.319265583]: Calculated 21 splinepoints terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check [arm_controller/joint_trajectory_controller-1] process has died [pid 27186, exit code -6, cmd /home/ralab/Documents/ros/devel/lib/cob_trajectory_controller/cob_trajectory_controller __name:=joint_trajectory_controller __log:=/home/ralab/.ros/log/1f275a8e-90fb-11e8-bbfd-7085c274b189/arm_controller-joint_trajectory_controller-1.log]. log file: /home/ralab/.ros/log/1f275a8e-90fb-11e8-bbfd-7085c274b189/arm_controller-joint_trajectory_controller-1*.log I am using ROS Indigo (cob_trajectory_controller is from indigo-dev), Ubuntu 14.04 32bit, Schunk PowerCube and modular robotics are from Indigo Any help would be great! Thank you Kyle
↧
Search

Controlling two robots: please help me get started (Action client not connected: /follow_joint_trajectory)

July 27, 2018, 6:40 am
$
0
0
**edit ---** [as of four years ago](https://groups.google.com/forum/#!topic/moveit-users/NZfk2PfnxWM) there was apparently no way to use MoveIt! with multiple robots, other than to combine them into a single URDF and treat them as one robot. This could work for me but then I guess the joints on the two robots would have to have different names for purposes of the controller? **initial content:** As an early attempt at simultaneously using two UR10s in a Gazebo simulation (and afterwards in the lab) I first modified the `universal_robot package files ur10.launch` and `ur10_moveit_planning_execution.launch` to use my own robot xacro (which at this stage is pretty much the same as `ur10_joint_limited_robot.urdf.xacro`). There are two launch files to get this simulation running and have MoveIt! operational. This initial step is working well. The next step in my plan for using two robots was to employ the `group` tag around this robot and around the `moveit_config/launch/move_group.launch` include as shown here in the two launch files. Here is the second launch file: The first one works as expected but the second one yields [ WARN] [1532698585.718194685, 368.013000000]: Waiting for /follow_joint_trajectory to come up [ WARN] [1532698591.765929321, 374.013000000]: Waiting for /follow_joint_trajectory to come up [ERROR] [1532698597.822045680, 380.018000000]: Action client not connected: /follow_joint_trajectory The only modification between these files and the two that work fine is the addition of the `` tag. Here are two questions. Can you say what the problem is with MoveIt! and can you tell me if this will be a good approach for using a second robot? I'm thinking that there will be a problem with `robot_state_publisher` since `tf` does not end up in the "placer" namespace (the topic is just `/tf`).
↧
↧

Moveit Octomap Not Allowing Command Planning or Execution

July 27, 2018, 11:41 am
$
0
0
Hi all, I've been trying to hook up Moveit so that my robot can avoid obstacles using openni_tracker and openni_launch. I've added octomap capabilities to my demo.launch file as: My process for getting point cloud data to appear and for the robot to avoid obstacles encountered in the point cloud is: ~$ roslaunch openni_launch openni.launch ~$ rosrun openni_tracker openni_tracker Unfortunately at this point the point cloud data does not appear until I issue the manual brute-force command: ~$ rosrun tf static_transform_publisher 0 0 0 0 0 0 /world /camera_link 100 This causes point cloud data to appear and update at the appropriate rate, but I can't execute or plan commands until I have killed the process where I create a transform link, but then the point cloud doesn't update as I would have hoped. Can anyone let me know if I'm making any incorrect assumptions or doing anything here that won't work and could be causing this issue? I can supply any other files that might be necessary to diagnose the issue as well, just let me know!
↧

Controlling MoveIt Marker with a Novint Falcon

July 30, 2018, 12:30 pm
$
0
0
I need to use a Novint Falcon haptic controller to move a 6 DOF modular Schunk arm. I have the arm set up in MoveIt and all the path planning works but I need to use the Falcon as a Joystick instead of a PS3/XBox controller. What can I do to get started?
↧

Using Novint Falcon Haptic Device as Joystick in MoveIt

July 30, 2018, 12:33 pm
$
0
0
I need to use a Novint Falcon haptic controller to move a 6 DOF modular Schunk arm. I have the arm set up in MoveIt and all the path planning works but I need to use the Falcon as a Joystick instead of a PS3/XBox controller. What can I do to get started?
↧

How to set a sequence of goals in moveit?

July 11, 2018, 2:55 am
$
0
0
Hi everyone, I would like to give my robot a sequence of goals such that by pushing plan & execution in Rviz it is possibile to make the robot reach every single goal serially. Does anyone know how I could implement this? Any help is appreciated. Thanks a lot. Ros version: kinetic Ubuntu 16.04
↧
↧

Pick and Place using 2 hands

July 31, 2018, 11:02 am
$
0
0
I want to do a bimanual pick and place task for an object at a known position of a known shape using Moveit. I have been using [this tutorial](http://docs.ros.org/kinetic/api/moveit_tutorials/html/doc/pick_place/pick_place_tutorial.html) for reference. But, since this tutorial is for one hand, I am unable to understand how to correctly specify the end effector in the srdf, since there will be 2 end effectors in this case, with different parent links. Also, I am unable to find any example code where something similar has been successfully implemented. It would be great if somebody could suggest a good reference for this.
↧

Using State Lattice Motion Planning for Arm Control with MoveIt!

July 31, 2018, 1:20 pm
$
0
0
I am currently working on implementing and extending Ben Cohen's work on [Search Based Planning for Manipulators](https://ieeexplore.ieee.org/abstract/document/5509685/). I have created a model of our arm in Gazebo and was hoping to leverage MoveIt! planning plugins to handle the planning aspects. The two planning library plugins I was considering were OMPL and SBPL. **Search-based Planning Library (SBPL)** SBPL seems to be the library written by Cohen for demonstrating his algorithm. There is an associated MoveIt! plugin that seemed to work back in 2016 based on other ROS Answers questions, but seems to no longer be fully supported and documentation on the plugin is sparse. In the MoveIt! documentation, it notes that [Integration (of SBPL) into latest version of MoveIt! is work in progress.](http://moveit.ros.org/documentation/planners/) and there is an [open issue](https://github.com/ros-planning/moveit/issues/101) about it on Github. *Does anyone know the status of reintegrating the SBPL plugin?* **Open Motion Planning Library (OMPL)** OMPL is the default planning plugin with better documentation. The main issue I ran into was the fact that the MoveIt! and OMPL interface seems to abstract away the concept of the robot into a pure planning problem by the time it gets to the OMPL planner, which would make it hard to construct an appropriate state lattice with motion primitives. One idea I had to work around this was to have my custom planner instantiate a ROS node that would subscribe to topics about the world and the arm in order to create the state lattice, plan using the lattice, and then pass the created plan to MoveIt! through the OMPL plugin. *Would it be possible to implement a state-lattice based planner in OMPL and does my workaround sound feasible?* **Writing my own custom planner** If the two libraries above don't work, my last recourse would be to create my own plugin and implement things from scratch. I have asked about implementing custom planners [previously](https://answers.ros.org/question/298345/different-ways-to-implement-custom-planners-with-moveit/) but *I would definitely appreciate any further information about implementing custom planner plugins as well as any other advice for tackling this.* Thank you for taking the time to answer my questions.
↧
Search

Bimanual Pick and Place

August 1, 2018, 3:57 am
$
0
0
## Problem Description ## I have been attempting to modify the pick and place tutorial for panda arm from [this tutorial](http://docs.ros.org/kinetic/api/moveit_tutorials/html/doc/pick_place/pick_place_tutorial.html) for a bimanual pick and place. I am working on a customised humanoid where there are 2 torso joints, and 5 joints on each arm and a 4 fingered hand attached to each hand. I am using ROS Kinetic on Ubuntu 16.04. As told in [this answer](https://answers.ros.org/question/299183/pick-and-place-using-2-hands/), I have created 4 planning groups. Here are the relevant snippets from my SRDF files. And my end effector is described as: I also have a move group for the upper body of the robot, which includes the torso and both hands. In the pick and place code, I have one function for opening the gripper and one function for closing the gripper, which includes all joints of the robot that would have a role to play for correctly grasping the object. void openGripper(trajectory_msgs::JointTrajectory& posture) { // BEGIN_SUB_TUTORIAL open_gripper /* Add both finger joints of panda robot. */ posture.joint_names.resize(12); posture.joint_names[0] = "torso_1_joint"; posture.joint_names[1] = "torso_2_joint"; posture.joint_names[2] = "lh_arm_0_joint"; posture.joint_names[3] = "lh_arm_1_joint"; posture.joint_names[4] = "lh_arm_2_joint"; posture.joint_names[5] = "lh_arm_3_joint"; posture.joint_names[6] = "lh_arm_4_joint"; posture.joint_names[7] = "rh_arm_0_joint"; posture.joint_names[8] = "rh_arm_1_joint"; posture.joint_names[9] = "rh_arm_2_joint"; posture.joint_names[10] = "rh_arm_3_joint"; posture.joint_names[11] = "rh_arm_4_joint"; /* Set them as open, wide enough for the object to fit. */ posture.points.resize(1); //number of waypoints posture.points[0].positions.resize(12); //number of joints /*point p and joint j --- joint_names corresponds to points

.positions*/ // positions are in the joint space // open - gripper -- ready posture.points[0].positions[0] = 0.00; posture.points[0].positions[1] = 0.00; posture.points[0].positions[2] = 0.1792; posture.points[0].positions[3] = -1.0268; posture.points[0].positions[4] = 0.1629; posture.points[0].positions[5] = 1.6461; posture.points[0].positions[6] = -1.0593; posture.points[0].positions[7] = -0.1792; posture.points[0].positions[8] = 1.2224; posture.points[0].positions[9] = -0.1629; posture.points[0].positions[10] = -1.6461; posture.points[0].positions[11] = 1.0593; // END_SUB_TUTORIAL } This is the open_gripper function and the closed gripper function is defined in a similar manner. In my "pick" function, I have specified the target position of the parent link of the end effector, to be center of the object that will be manipulated. In order to simplify the problem, I use a fixed sized object at a fixed position. void pick(moveit::planning_interface::MoveGroupInterface& move_group) { // BEGIN_SUB_TUTORIAL pick1 // Create a vector of grasps to be attempted, currently only creating single grasp. // This is essentially useful when using a grasp generator to generate and test multiple grasps. std::vector grasps; grasps.resize(1); // Setting grasp pose // ++++++++++++++++++++++ // This is the pose of panda_link8. |br| // From panda_link8 to the palm of the eef the distance is 0.058, the cube starts 0.01 before 5.0 (half of the length // of the cube). |br| // Therefore, the position for panda_link8 = 5 - (length of cube/2 - distance b/w panda_link8 and palm of eef - some // extra padding) //The pose of the parent link of the end effector during a grasp --> not the position of any link in the end effector grasps[0].grasp_pose.header.frame_id = "base_footprint"; //base frame grasps[0].grasp_pose.pose.orientation = tf::createQuaternionMsgFromRollPitchYaw(-M_PI / 2, -M_PI / 4, -M_PI / 2); // (roll,pitch,yaw) grasps[0].grasp_pose.pose.position.x = 0.379; //0.379 grasps[0].grasp_pose.pose.position.y = 0.4545; //0.4545 grasps[0].grasp_pose.pose.position.z = 0.2; //0.544 // Setting pre-grasp approach // ++++++++++++++++++++++++++ // The approach direction to take before picking up the object /* Defined with respect to frame_id */ grasps[0].pre_grasp_approach.direction.header.frame_id = "base_footprint"; /* Direction is set as positive x axis */ grasps[0].pre_grasp_approach.direction.vector.z = 1.0; grasps[0].pre_grasp_approach.min_distance = 0.2; grasps[0].pre_grasp_approach.desired_distance = 0.4; // Setting post-grasp retreat // ++++++++++++++++++++++++++ /* Defined with respect to frame_id */ // The retreat direction to take after the grasp has been completed --> object is attached to the gripper grasps[0].post_grasp_retreat.direction.header.frame_id = "base_footprint"; /* Direction is set as positive z axis */ grasps[0].post_grasp_retreat.direction.vector.y = 1.0; grasps[0].post_grasp_retreat.min_distance = 0.1; grasps[0].post_grasp_retreat.desired_distance = 0.25; // Setting posture of eef before grasp // +++++++++++++++++++++++++++++++++++ openGripper(grasps[0].pre_grasp_posture); // END_SUB_TUTORIAL // BEGIN_SUB_TUTORIAL pick2 // Setting posture of eef during grasp // +++++++++++++++++++++++++++++++++++ closedGripper(grasps[0].grasp_posture); // END_SUB_TUTORIAL After this, I have added 3 collision objects in the scene (2 support surfaces and 1 object) as done in the tutorial. This is the main function: int main(int argc, char** argv) { ros::init(argc, argv, "pem_pick_place"); //Node Handle ros::NodeHandle nh; ros::AsyncSpinner spinner(1); spinner.start(); ros::WallDuration(1.0).sleep(); moveit::planning_interface::PlanningSceneInterface planning_scene_interface; moveit::planning_interface::MoveGroupInterface group("complete_robot"); //Move Group for the poses group.setPlanningTime(45.0); addCollisionObjects(planning_scene_interface); // Wait a bit for ROS things to initialize ros::WallDuration(1.0).sleep(); pick(group); ros::WallDuration(1.0).sleep(); place(group); ros::waitForShutdown(); return 0; } I first run the launch file for my moveit configuration, which loads the robot model, then in a separate terminal, I run the executable for the cpp file. ## Errors ## Moveit [ WARN] [1533120527.279616830]: Interactive marker 'EE:goal_rh_fftip' contains unnormalized quaternions. This warning will only be output once but may be true for others; enable DEBUG messages for ros.rviz.quaternions to see more details. [ INFO] [1533120565.018137428]: Planning attempt 1 of at most 1 [ WARN] [1533120565.020146078]: Choice of end-effector for group 'complete_robot' is ambiguous. Assuming 'ee_lh' [ INFO] [1533120565.060632190]: Added plan for pipeline 'pick'. Queue is now of size 1 [ERROR] [1533120565.066561036]: No sampler was constructed [ INFO] [1533120565.066653531]: Manipulation plan 0 failed at stage 'reachable & valid pose filter' on thread 0 [ WARN] [1533120565.067049296]: All supplied grasps failed. Retrying last grasp in verbose mode. [ INFO] [1533120565.067228491]: Re-added last failed plan for pipeline 'pick'. Queue is now of size 1 [ INFO] [1533120565.069150446]: Manipulation plan 0 failed at stage 'reachable & valid pose filter' on thread 2 [ INFO] [1533120565.069377462]: Pickup planning completed after 0.046757 seconds [ INFO] [1533120566.117776927]: Planning attempt 1 of at most 1 [ERROR] [1533120566.118297808]: Attached body 'object' not found Pick and Place [ WARN] [1533120565.070406529]: Fail: ABORTED: No motion plan found. No execution attempted. [ WARN] [1533120566.119674534]: Fail: ABORTED: Must specify group in motion plan request I also run `rostopic echo /pickup/status` and I get the following: --- header: seq: 16451 stamp: secs: 1533120892 nsecs: 262651730 frame_id: '' status_list: - goal_id: stamp: secs: 1533120564 nsecs: 959055662 id: "/pem_pick_place-1-1533120564.959055662" status: 4 text: "No motion plan found. No execution attempted." ## Questions ## 1. Since I need the robot to bend (move both the torso joints) in order to grasp the object, is it correct that I have specified the desired joint angles of the torso joints in my open_gripper() and closed_gripper() function? Or should I just specify the joint angle values of the stated end effectors? 2. In my main function for the pick and place code, where we specify the desired move_group for manipulation, what move group should be specified? I have currently specified the move_group "complete_robot", but I get a warning which says ambiguous end effector for that move group. 3. In the pick function, the tutorial code uses the function "`tf::createQuaternionMsgFromRollPitchYaw(-M_PI / 2, -M_PI / 4, -M_PI / 2);`". I dont understand how the reference roll, pitch and yaw values for any robot are defined. 4. Are the number of planning attempts equal to the number of grasp messages specified? 5. [This indigo pick and place tutorial](https://github.com/ros-planning/moveit_tutorials/blob/indigo-devel/doc/pr2_tutorials/pick_place/src/pick_place_tutorial.cpp) does not use `tf::createQuaternionMsgFromRollPitchYaw(-M_PI / 2, -M_PI / 4, -M_PI / 2);`, but instead uses `geometry_msgs::PoseStamped p;` How is it different from what is done in the ROS Kinetic tutorial for pick and place?
↧

PX4 moveit iris.xacro

August 1, 2018, 11:40 am
$
0
0
I have a problem with moveit and PX4 iris model. More specifically I get that error: Running xacro failed. The terminal error output was "Undefined substitution argument rotors_description_dir None when processing file: /home/john/src/Firmware/Tools/sitl_gazebo/models/rotors_description/urdf/iris.xacro Could anyone help? I'm trying to apply OMPL algorithms in iris.xacro model through Moveit. ROS: kinetic
↧
↧

Velocity Control on Fanuc Robot

August 2, 2018, 6:42 am
$
0
0
I'm currently trying implement path planning and execution of dense cartesian trajectories on fanuc arms. I've had reasonable success planning the path provided that I ignore the specified velocities on the points I'm planning to. I have read some threads which said to modify the duration_from_previous in a robot_trajectory::RobotTrajectory object to achieve different traversal speeds between points in a trajectory. Although this approach works perfectly well in simulation, upon moving the actual arm, I find that the arm only moves at constant velocity. Is there currently any way to adjust movement speed of a real, hardware fanuc arm? Any input would be greatly appreciated.
↧

Error when using Ikfast translation3D with MoveIt : "Can only compute FK for Transform6D IK type!"

August 2, 2018, 5:44 pm
$
0
0
Hi, I'm willing to plan for a 3dof leg with moveit, using an ikfast transform3D plugin, but it fails with the error "Can only compute FK for Transform6D IK type!". The IK is OK (tested in rviz with the moveit plugin). I use setPositionTarget, and was thinking that orientation wasn't used. For now, i've tweaked computeFK() in ikfast_moveit_plugin.cpp to return a dummy orientation, but 1) it's ugly and 2) the planning often do not behave correctly, indicating that the fix isn't correct. What do i miss ? Context : debian stretch / Ros melodic
↧

Moving custom robotic arm to desired position in rviz using Moveit

August 4, 2018, 5:26 am
$
0
0
My arm doesn't move to the selected finish position when planning and no trail is shown when trail checkbox is on. I have selected the start and finish states on pressing plan there is no motion Please help. I'm attaching urdf file's code link [URDF of robotic arm](https://drive.google.com/file/d/1939ZLIBAOAzG_Z23M87UjlXzGnF9SryB/view?usp=sharing) [Image of start and end positions in Rviz](https://drive.google.com/file/d/1Qae36ba1HeveD5JiZXH6YeYn5hAWR-82/view?usp=sharing)
↧
Viewing all 1441 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>