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

Understanding and using IterativeParabolicTimeParameterization

$
0
0
I’m a little bit confused about IterativeParabolicTimeParameterization and how to use it : 1. As I understood it is currently used internally by Moveit! after the planner found the IK solution, to add velocities and accelerations on the trajectory while checking for collisions. And then we can use it again to modify the trajectory as we wish. Is it correct ? 2. What are all the things we can do with IterativeParabolicTimeParameterization ? From the source code it’s hard for me to guess every possibility. What are the different options we have to modify a trajectory ? And what kind of modification can we make (on position, velocity, acceleration) ? 3. I am currently having issues with my robot (6dof robotic arm), the velocity from the Moveit! trajectory is weird : sometimes it decreases in the middle of the trajectory (and then increases again), making the robot almost stop multiple times in one trajectory, which is not acceptable for my use case. (that’s not the point here, but this error only occurs on kinetic, I was not having this issue at all on indigo. For more info about what I mean, check out https://github.com/ros-planning/moveit_core/issues/167, I get the exact same kind of behavior). My question is : Could IterativeParabolicTimeParameterization be responsible of that (and what could possibly have happened between indigo and kinetic), and is there a way I can ask Moveit! to make the velocity increasing, then staying constant, then decreasing ? 4. Can IterativeParabolicTimeParameterization modify only a part of the trajectory ? For example I also would like to reduce the acceleration only at the very beginning and at the very end of the trajectory, in order to enable the robot to start and stop more slowly, while keeping the same behavior for the rest of the trajectory. (something like 3% - 94% - 3% of the trajectory : the 94% in the middle stays the same, or adapt to keep the same global time with the modified beginning and ending) 5. I was only speaking about IterativeParabolicTimeParameterization in this question. Is there another way to do what I want to do in those questions, that I didn’t think about ? Any help would be appreciated :) Thanks in advance

How to make move_group_python node move the pr2 in gazebo

$
0
0
How can i make the move_group_python_interface_tutorial.py to move the pr2 robot inside the gazebo. I have moved the pr2 inside the gazebo from [this](http://picknik.io/moveit_wiki/index.php?title=PR2/Gazebo/Quick_Start) tutorial from a moveit_planning_execution.launch file and i've used [this](http://docs.ros.org/indigo/api/moveit_tutorials/html/doc/pr2_tutorials/planning/scripts/doc/move_group_python_interface_tutorial.html) tutorial to move a pr2 robot inside the rviz. When try to put this node inside the moveit_planning_execution.launch file which contains the planning and execution component of moveit, the robot moves inside the rviz as the python code describes but the robot inside the gazebo is not moving. According to the move_group_interface_python tutorial after i uncomment the `# group.go(wait=True)` line shouldn't the pr2 inside gazebo also move sinnce all the controllers are active. How should i complete this task, i want to move a robot(right now pr2) from a action client/moveit python node, but i dont know right now how can i do it.

Failed path execution, MoveIt+Rviz, PATH_TOLERANCE_VIOLATED in Ros Control

$
0
0
Hi, I am using Moveit with Ros-Control for doing path planning on a custom robotic arm. For Ros Control, ros-control-boileplate is being used, and read write with actuator is being done on serial. Moveit/Rviz plans the necessary path for the required goal position, however after pressing execute following error occurs: [ WARN] [1484402519.787975773]: Controller xyz/position_trajectory_controller failed with error code PATH_TOLERANCE_VIOLATED [ WARN] [1484402519.788105613]: Controller xyz/position_trajectory_controller reports status ABORTED [ INFO] [1484402519.936339345]: ABORTED: Solution found but controller failed during execution I am executing, robot_moveit_config -> demo.launch, and [robot_hardware.launch](https://github.com/davetcoleman/ros_control_boilerplate/blob/kinetic-devel/rrbot_control/launch/rrbot_hardware.launch) from ros_control_boilerplate I tried playing with goal and path parameters of the joint trajectory controller through the .yaml file, however the same error continued. Please let me know, if anyone can offer insight on this. Thanks

which node is motion planner in moveit?

$
0
0
**QUESTION1:** I wonder **which node is motion planner in moveit**? This passage raises my question: > MoveIt! can talk to the motion> planners through the plugin interface.> We can use any motion planner by> simply changing the plugin. This> method is highly extensible so we can> try our own custom motion planners> using this interface. **The move_group> node talks to the motion planner> plugin via the ROS action/services.**> The default planner for the move_group> node is OMPL> (http://ompl.kavrakilab.org/) **QUESTION2:** As the **figure shown below**, while there are nodes of **action_topics** in the namespace of **place and pickup** respectively, there is also a node of **action_topics** in the namespace of **move_group**, which **seems redundant to me**, there must be something I misunderstand. **QUESTION3:** What's more, **they form a loop in combination with move_group and rviz**, I do not quite understand how things work Here is the **rqt_graph** for **moveit_config demo.launch** ![image description](/upfiles/14845574034420503.png)

DistanceToCollision within a Moveit Planner

$
0
0
Hello, I am trying to create a planner plugin within MoveIt, based on the CHOMP Planner already implemented. For this I need a distance function which returns the minimum distance between robot and environment, which DistanceToCollision provides. In order for the obstacles to be recognized and to avoid: https://github.com/ros-planning/moveit/issues/166 I use `planning_scene_interface_.getObjects()`. All of this works when the c++ code is run with moveit running, however when added to the planner this line causes an infinite loop, perhaps because the PlanningSceneInterface requires move_group, and the planner is run from it. What could be done to solve this? Or alternatively is there another function that calculates distance to environment which does not require the PlanningSceneInterface and would work in the planner? Thank you in advance.

Failed to validate trajectory: couldn't receive full current joint state within 1s error

$
0
0
hi! I am learning how to work with gazebo+moveit on ros indigo. I am following the book "Mastering ROS for Robotics Programming" and i am working with seven_dof_arm. I tried to execute only moveit, planned a motion and all did well and the same happen when i only work with gazebo only and control by terminal a joint to move. My problem happens when i have the two running and somehow i cant execute my planning from moveit to gazebo, it gives always this error: "Failed to validate trajectory: couldn't receive full current joint state within 1s". I don't known how to resolve this problem... i have gazebo 2, ros indigo, moveit last update (from january 2017), ubuntu 14.04 trusty. My result in the terminal when i try to plan and execute a valid state: [ INFO] [1484581574.863269930, 60.697000000]: Planning request received for MoveGroup action. Forwarding to planning pipeline. [ INFO] [1484581574.864123376, 60.697000000]: No optimization objective specified, defaulting to PathLengthOptimizationObjective [ INFO] [1484581574.864214951, 60.697000000]: No planner specified. Using default. [ INFO] [1484581574.864274631, 60.697000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581574.864428301, 60.697000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581574.864680354, 60.697000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581574.864967007, 60.697000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581574.865112877, 60.697000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581574.865192578, 60.697000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581574.865431756, 60.697000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581574.865522202, 60.697000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581574.865631368, 60.697000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.092653727, 60.870000000]: LBKPIECE1: Created 132 (30 start + 102 goal) states in 116 cells (28 start (28 on boundary) + 88 goal (88 on boundary)) [ INFO] [1484581575.096303094, 60.873000000]: LBKPIECE1: Created 90 (53 start + 37 goal) states in 77 cells (51 start (51 on boundary) + 26 goal (26 on boundary)) [ INFO] [1484581575.099875817, 60.876000000]: LBKPIECE1: Created 93 (39 start + 54 goal) states in 78 cells (38 start (38 on boundary) + 40 goal (40 on boundary)) [ INFO] [1484581575.148138305, 60.908000000]: LBKPIECE1: Created 152 (47 start + 105 goal) states in 137 cells (46 start (46 on boundary) + 91 goal (91 on boundary)) [ INFO] [1484581575.219947981, 60.970000000]: ParallelPlan::solve(): Solution found by one or more threads in 0.355519 seconds [ INFO] [1484581575.220561589, 60.970000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581575.220679319, 60.971000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581575.220783265, 60.971000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.220883439, 60.971000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.222415665, 60.971000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581575.222642371, 60.971000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.225482043, 60.975000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581575.225660210, 60.975000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.271342086, 60.995000000]: LBKPIECE1: Created 55 (18 start + 37 goal) states in 43 cells (18 start (18 on boundary) + 25 goal (25 on boundary)) [ INFO] [1484581575.376397773, 61.029000000]: LBKPIECE1: Created 129 (46 start + 83 goal) states in 114 cells (45 start (45 on boundary) + 69 goal (69 on boundary)) [ INFO] [1484581575.379188044, 61.029000000]: LBKPIECE1: Created 244 (142 start + 102 goal) states in 221 cells (132 start (132 on boundary) + 89 goal (89 on boundary)) [ INFO] [1484581575.396009612, 61.039000000]: LBKPIECE1: Created 154 (55 start + 99 goal) states in 140 cells (53 start (53 on boundary) + 87 goal (87 on boundary)) [ INFO] [1484581575.865887723, 61.440000000]: ParallelPlan::solve(): Solution found by one or more threads in 0.645353 seconds [ INFO] [1484581575.866652837, 61.441000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581575.866837889, 61.441000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.867170960, 61.441000000]: LBKPIECE1: Attempting to use default projection. [ INFO] [1484581575.867379753, 61.441000000]: LBKPIECE1: Starting planning with 1 states already in datastructure [ INFO] [1484581575.958625159, 61.503000000]: LBKPIECE1: Created 126 (73 start + 53 goal) states in 113 cells (70 start (70 on boundary) + 43 goal (43 on boundary)) [ INFO] [1484581575.965867380, 61.509000000]: LBKPIECE1: Created 126 (60 start + 66 goal) states in 114 cells (58 start (58 on boundary) + 56 goal (56 on boundary)) [ INFO] [1484581576.509494547, 61.929000000]: ParallelPlan::solve(): Solution found by one or more threads in 0.642884 seconds [ INFO] [1484581576.510056518, 61.929000000]: SimpleSetup: Path simplification took 0.000456 seconds and changed from 7 to 2 states [ INFO] [1484581577.430458282, 62.637000000]: Received new trajectory execution service request... **[ WARN] [1484581578.900054544, 63.644000000]: Failed to validate trajectory: couldn't receive full current joint state within 1s** [ INFO] [1484581578.900165733, 63.644000000]: Execution completed: ABORTED

How do I set the start position for the group.asyncMove() command?

$
0
0
Hello all, I am writing a script in C++ to move a universal robot with linear or ptp movements depending on paramters set in a configuration file. For example I want to move between Points 1,2,3 linear and then switch to ptp for points 4,5,6 and then switch back to lin again for 7,8,9. The basic script is working but there is one big problem I could not solve yet. In order to move from 3 to 4 and 6 to 7 I have to tell the planner that the start state of the robot has been changed. That works for "group.computeCartesianPath" with "group.setStartStateToCurrentState();" but the same command does not work with "group.asyncMove()". Also group.setStartState(*group.getCurrentState()) as well as another command I found in a example script (but I can not remember it) don't work. I did not even receive a error message like "Motion Planning should always start at the current position of the robot. Ignoring new start State and planning from current state". My next try was to create a plan and use group.execute() after setting the new start state with something like plan.start_state_=group.getCurrentState() but I got some new error messages and before I spend some hours on solving these I wanted to know beforehand if the "plan" approach is going to work eventually and if there is a simpler solution. So my question: How do I set the start position for the group.asyncMove() command? Thank you.

MoveIt! Installation

$
0
0
Hi, I've been trying to install MoveIt! on ROS Indigo in Ubuntu 14.04 and have been running into issues. I first tried to install it using the binary installation instructions: sudo apt-get install ros-indigo-moveit-ros However, it says: *Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: ros-indigo-moveit-full : Depends: ros-indigo-moveit-commander but it is not going to be installed Depends: ros-indigo-moveit-ros but it is not going to be installed Depends: ros-indigo-moveit-setup-assistant but it is not going to be installed* I have also tried installing it from source. It seemed to work after a few times but when I try to run a tutorial program, it says "ImportError: No module named moveit_commander" I tried reinstalling ROS multiple times to no avail. I've been looking around online but it seems like other people are having similar issues. Has any been able to successfully install MoveIt? Thanks

where is the document for namespace of move_group_interface

$
0
0
In book, Master ROS for Robotics Programming. I notice this **header file** below //MoveIt! header file #include int main(int argc, char **argv) { ros::init(argc, argv, "test_random_node", ros::init_options::AnonymousName); // start a ROS spinning thread ros::AsyncSpinner spinner(1); spinner.start(); // this connects to a running instance of the move_group node // Here the Planning group is "arm" move_group_interface::MoveGroup group("arm"); // specify that our target will be a random one group.setRandomTarget(); // plan the motion and then move the group to the sampled target group.move(); ros::waitForShutdown(); } I tried to find the document for this header, but just found [**planning_interface namespace**](http://docs.ros.org/kinetic/api/moveit_ros_planning_interface/html/classmoveit_1_1planning__interface_1_1MoveGroup.html) for **move_group.h file** , instead of **move_group_interface namespace**. **QUESTION1:** Why? **QUESTION2:** Or, maybe actually, it is not a question for ROS but for C++ instead? **EDIT1** Document of [MoveGroupInterface](http://docs.ros.org/kinetic/api/moveit_ros_planning_interface/html/classmoveit_1_1planning__interface_1_1MoveGroupInterface.html), where it shows the header: #include **QUESTION3:** If I want to use **MoveGroupInterface class**, how should I write the header **correctly in my own code**?

Using setJointValueTarget and setPoseTarget have different results

$
0
0
The following code works, if the target is defined by Joint Value. But if I define the same point by Pose (as in the comment section), the planning path is different every time I run the code. And some times the robot is not able to find the path... I am using hydro on UR10, moveit version is 0.5.20. ubuntu 12.04. I get the position and orientation value of 'goal' by using command: `rosrun tf tf_echo base_link ee_link`, when the end effector reach 'joints'. So basically, 'goal' and 'joints' are the same position. Why `setJointValueTarge` is working while `setPoseTarget` is not? int main(int argc, char **argv) { ros::init(argc, argv, "move_group_test"); ros::AsyncSpinner spinner(1); spinner.start(); moveit::planning_interface::MoveGroup group("manipulator"); group.setPlannerId("ESTkConfigDefault"); std::map joints; joints["shoulder_pan_joint"] = 0; joints["shoulder_lift_joint"] = -0.5648; joints["elbow_joint"] = -1.06; joints["wrist_1_joint"] = -1.69; joints["wrist_2_joint"] = -1.76; joints["wrist_3_joint"] = 8.572; group.setJointValueTarget(joints); group.move(); /* geometry_msgs::Pose goal; goal.position.x = 0.555; goal.position.y = 0.146; goal.position.z = 1.156; goal.orientation.w = 0.991428; goal.orientation.x = 0.0085588; goal.orientation.y = -0.087665; goal.orientation.z = -0.0964952; group.setPoseTarget(goal); group.move(); */ }

MoveIt: Is there a trajectory-cache?

$
0
0
Hello! For my current project on picking with a UR, I'm looking for a cache for planned paths. Some movements (e.g. from the put position back to a start position) are repeated for every object and the planning needs some time (around 2 seconds) which I'd like to save by storing plans in a DB (doesn't even need to be persistent) so that if I request the same start and end-joints I can look up the trajectory and execute it directly (assuming a constant collision environment). Is there something available or do I have to implement it?

Using MoveIt with ros_control - why are /joint_states all zero?

$
0
0
Hi, I'm having real difficulty configuring MoveIt with ros_control for my robot. I have used the SetupAssistant to create a config package, then have made some of my own launch and config files following tutorials. I have managed to get to the point where everything seems to launch successfully with no errors, but when I echo /joint_states or publish the joint positions that I am getting in my RobotHW class, I am getting a constant array of zeros, even though I am executing a goal in RViz. Interestingly, if I echo /arm_joint_controller/follow_joint_trajectory/goal, then this does seem to give me a series of joint positions when a goal is executed. I have included my main launch and configuration files below. If there is any other info which would help please let me know and I will include it. If anyone could take a look and tell me where I'm going wrong I would be eternally grateful - after many hours it's starting to drive me mad! :p Thanks. spawn_bolt_arm.launch: arm_joint_publisher.launch: arm_trajectory_controller.launch: moveit_planning_execution.launch: bolt_arm_moveit_controller_manager.launch.xml: arm_joint_states.yaml: arm_joint_publisher: type: "joint_state_controller/JointStateController" publish_rate: 50 arm_trajectory_control.yaml: arm_joint_controller: type: "position_controllers/JointTrajectoryController" joints: - base_joint - shoulder_joint - elbow_joint - wrist_joint - wrist_rotate_joint gripper_joint_controller: type: "position_controllers/JointTrajectoryController" joints: - left_gripper_joint - right_gripper_joint controllers.yaml: controller_manager_ns: controller_manager controller_list: - name: arm_joint_controller action_ns: follow_joint_trajectory type: FollowJointTrajectory default: true joints: - base_joint - shoulder_joint - elbow_joint - wrist_joint - wrist_rotate_joint - name: gripper_joint_controller action_ns: follow_joint_trajectory type: FollowJointTrajectory default: true joints: - left_gripper_joint - right_gripper_joint

[MoveIt]Goal state colliding mistake in RVIZ

$
0
0
Hi, I followed the "Setup Assistant Tutorial" to build a config package for my robo-arm. After that I launched the "demo.launch" of the package moveit_config .I can see the model of my robo-arm.But when I move the Interactive Marker.It seems that the goal state colliding detecting mistake. The links far from each other obviously turned red color. I need your help.Thank you !!

[MoveIt]Goal state colliding detecting has mistakes.

$
0
0
Hi, I followed the "Setup Assistant Tutorial" to build a config package for my robo-arm. After that I launched the "demo.launch" of the package moveit_config .I can see the model of my robo-arm.But when I move the Interactive Marker.It seems that the goal state colliding detecting ![had mistakes](http://). The links far from each other obviously turned red color. I need your help.Thank you !! ![image description](https://lh3.googleusercontent.com/nSlVjp2SyBZVX0Hqn5uLQvh9MJ6Pjy063snZdZ4OJzIi4pFpm8JG1ViPlEDJmYwkM4pQa_ROiPYBHkP4ydRiwnJZyq8jl0WrWRIwD-wsnL0ZuJ7pj6cpBRfWBu6K178Q36TCsq0D0AvkIm4hTHeVj0uhl1e9VZjGOWhtLMyS9bLXXU9RjZ1mfSWG652fevAAU_zCe47BtNPvL-TKGzHqF5d9qGMv3pqADsXwcpYuX3hQFtuEOHVQgo_te7MPF2SPjowy8mx8erpsHfogIPB1RvTsbWspDfdC72jBrsVLU5S3n3nvPUrpWTbXrEYUviPNRwlE1ATlkMM2DHv9HKlX22c2s9wvWxAYoDfvz8WsA62ukHJgwARCqG_xfA-Xn88VvFGzDXqRqiYQvPHC01Aqam78gKDNkabcXdAyTSm5nZZgwsXnxu3J8rhvQos-KrhkcPlRD8U7PjReUabVFl8R4WM1Fd0E7DOTq9xS6RqdjmZeKaie4suFSnWLwTsmveY2X7yJH5nJh-8Cv-XJts8GREy6UbtAy19TLbJCJPPPjSNgla-_ADwwxlHkXjUBflJpx18-XI4OMzW0KUcWkNH2mwta9278smIwK9xhg7v8DZcoJEcD=w741-h740-no) ![image description](https://lh3.googleusercontent.com/rX6rAuiEyS9LRNZjIyNT5vVn3LsemLGPGkwsyLrpID1Dmk_AhJ638BzeehInajYFFMtF-Il0rJXxEl-kNuuM-bKqyeIIEfoOjtyCdm777p-hOsKKTyU3z57zdFy1sPg4BpCTGCOGzdW5TlE-_DofEa3rdtqSNNKXoNVEJ6YSIOK4fv8BsdoJiZ8E3yguXZceYlU24lExKq9bC_K5r37fbNFOXlIiFdjiQHTiUc7zrMXyf5vNCL5FB4G7f6I8S6xxkE9o99TMDftU9bbixgB0ydU7yQYc9oP63wetwul9EnBu5msYSqOWsAq_lanCemzPbJg-Gl3zUxipRcIfvWfU2VdcmOqidaC6jodQ0D78YZq2FQ859hsnm5PIyL---835LWPPGg4Gh8hU0sVamSAZFNVVYsMDF_74WDjuYuL2czvp4e-8thBkhblsfkawCrYgzgXx4pLlCvNBKId7FdMRJIQdMSpOE7zJOEjCxw7ypsng1GUnAz1BLe6Q9OQOSy_hTcdl4OJwo-L_9NoZF-3u--HU2_oVta8mZtbdqmn9-157gxStPnsPNK8HuVVkPkf_fH8i-EL-3lkLnIYHB2HWyS-V4XfMtNVmLESbLoAPIHnzMlCJCMqgnh6J2HDrDFKfFR14Sb-m0nApA_zV9nwtrZZwWtcqX79nweTA5eHViw=w902-h846-no) ![image description](https://lh3.googleusercontent.com/LyXtLpXhcAxJHZR2S56pIKWXcuUQcQc2WsxgHDPae3IpH6mse_L7xYuIJ3ZIIDjDqQLM-U5qiu-VzyMKdSBD1m0aUJwIuufECj57ZYJeiIJF2B6TUMiaW-DiPgmClS6eepyFBOsF0OdFjXNwhTJkahxnfoPVBp6V0kS9gZOVRATbREEPkpLEezSaorYpFnJt1oNWEB3r52cX04Y22usIBzHzuJTozacpzz8yzxUCwrehYm5j-0MamimbDHBYCG3FLHqmC5VUl444dKq5tzzxeCw-jdRfAaMpMEts7xcPYetweaYLJ93mSQaD81UdOmxspCYMLa1Z60xGrOZ9CGeRQ-JRh4DQPfkHC8uWzQnQLC1eVp2VkE9-oJmMNxqyEi1bgGrHIP3ZW4oGhC082uSJBcVFYepss-P8DZu68kDu9fP2aiGrUOTb3I3oa7Z738l_d8PfCUg-_vuWbmsMql0uvaFGO9g_DUjKDrx4MrgbgD0E54TvrrV1sV9Kiqev6C5sSbEnlONbNfe1RHbSkypP4Ucl1MhkFaOLzXVgE2BeA4-EPuRb3VVJMqBpq6W1-nIi61wDT7ZUKlrAIOMID0v8ykTjOtOLoQoLEMqOQ5ktqmaWs0vF=w643-h703-no) ![image description](https://lh3.googleusercontent.com/32rcVQ89LS_DLXlo2PCnKw5YW2l8AyhZfFHuJiYRyI6-a3iFZO4zKtWKk4qUKSpTRaD1ciASNxDkEmPIEX9OvrRo9Es9-AW507O5mNvmowaBlsO8qI0RO3RNptlZFirAYwvKmnpRSrjtT4S8j-T7g27ndDnT2aZSaIM-4-WxuBdokcWlqvWUBwbO36hmvUdLgumSjxml_8oTNBeGxpTd37xMkxHRGOqUm-3r5rMzrFjg3D6XyQ67AuyuJCxyLJl7T4HDIedRvEpYOvkSYIT6_HYg1vdfmzWTHFG4guNqCSiyuj8-g-YMzjTq-Aj5CH_8S9CC19eOpgVNbAuOKrj0CZThHprbuhxUiRI9UcFvxCI824AvFk_Gj0fhEd11-Qce5x0m3MvKVzswh9kCxY2BYaicBJmL0ipdO2teaaIx2rPjWflp2TT9-_luJiWDRQKPPqR6AHHW-6UQ7FtD1oXWnmB0KkiHPuNC1hxN5bUulTx7kOcodxl-SJa_4XJOhu_vYWYp-tjcY6fIFDjUEGSQtrIe3tvG1V2ZVN-AwkPjWOWooSpIDnkQIdJRJO_J6Z1EF115h3RqilOSziL2lN6VC5KhBlHhSZAuhKAw8NvhiBHTCdmkwNUt=w692-h472-no)

Generating IK solution for use in MoveIT for 5 DOF arm

$
0
0
I am working on a custom 5 DOF arm(image at the bottom). I have generated the URDF, the MoveIt configs etc for it. I want to have the basic IK, planning and collision detection features of MoveIt. Before programming my application, I tried running the simple planning in RViz, using the interactive marker etc. Now, since it is a 5 dof system, I had to enable "Allow Approximate IK solutions", for it to let me use the interactive markers. It was using OMPL by default. I tried planning for some random-valid goal states. The problem is that the planning success rate was very very low. 4 out of 5 times the planning failed. I also tried changing the planners from the dropdowns, but none of them were consistent in planning succesfully, all of them were failing quite frequently. After looking up this problem [here on Ros-Answers](http://answers.ros.org/question/10407/inverse-kinematics-solver/) and many other places, we found that IKFast would be what we should use, as it works reliably for 5 dof systems. After installing openrave and ikfast via source, we ran the commands to generate a IKfast cpp file(using [this tutorial](http://wiki.ros.org/Industrial/Tutorials/Create_a_Fast_IK_Solution)) for our robot model. We tried the TranslationDirection5D ik type. Now here we are getting a `tuple index out of range error` which is something that others have faced before and have not been able to solve. See [this](http://openrave-users-list.185357.n3.nabble.com/Struggling-to-get-ikfast-to-work-td4027761.html) and [this](http://openrave-users-list.185357.n3.nabble.com/IndexError-tuple-index-out-of-range-td4026855.html). Basically, we've now hit a wall trying to get the IK on my 5 dof robot to work properly. Openrave is not even able to generate an Ikfast cpp. Here'ss the exact error i get when i try to generate an ikfast cpp, Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 9521, in chaintree = solver.generateIkSolver(options.baselink,options.eelink,options.freeindices,solvefn=solvefn) File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 2281, in generateIkSolver chaintree = solvefn(self, LinksRaw, jointvars, isolvejointvars) File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 2796, in solveFullIK_TranslationDirection5D coupledsolutions,usedvars = solvemethod(rawpolyeqs2[index],newsolvejointvars,endbranchtree=[AST.SolverSequence([endbranchtree2])], AllEquationsExtra=AllEquations) File "/usr/local/lib/python2.7/dist-packages/openravepy/_openravepy_/ikfast.py", line 5226, in solveLiWoernleHiller hassinglevariable |= any([all([__builtin__.sum(monom)==monom[i] for monom in newpeq.monoms()]) for i in range(3)]) IndexError: tuple index out of range Is there a recommended way to get IKfast to generate a cpp or maybe even get the normal KDL to work reliably for my 5 dof system? I would really appreciate any kind of help to get this to work, thanks Here's the picture of the bot from RViz ![image description](/upfiles/14835631185155382.png)

moveit rviz cannot display executation

$
0
0
**moveit rviz cannot display executation from my own code or rviz command** Here is the rqt_graph for seven_dof_arm_config.demo launch from book, master ros for robotics programming ![image description](/upfiles/14849162169567704.png) ---------- I search solution from google, find someone says he thinks **topic /move_group/fake_controller_joint_states is ONLY published with one final joint state message**, so rviz ONLY display the final joint state. Here is the [link](https://github.com/ros-planning/moveit_ros/issues/278) ---------- On book, ros-by-example V2, **movement of execution of pi_robot can be visualized**. I think this is because **arbotix controller keeps updating /joint_state, so that rviz keeps updating the movement of pi_robot**. **Am I right?** Here is the rqt_graph. ![image description](/upfiles/14849164794890351.png) ---------- How can I visualize the **complete movement of execution** of the simulated robot?

How to do motion planing with closed loop chain/graph robot structure?

$
0
0
URDF supports only tree structure. SDF support graph structure but it is only for simulation. Moveit supports only URDF so I think I cant use it for motion planing (except if I close it with maths, witch is difficult). I think collada files supports closed loop chain but can I use it on ROS Moveit? Collada is working well with OpenRave but can it communicate with ROS so I can link it with my robot? This is the robot structure: ![image](https://s30.postimg.org/8jsm79qht/paint.jpg) Is there any way to suggest me how I can do motion planing with closed loop chain?

Obstacles management in Moveit

$
0
0
I would be delighted if someone can explain very clearly. I have recently started working on a robot that has a Jaco Arm. (MetraLab Scitos G5). I am using the ASUS xtion pro for the obstacle avoidance. Once this is done, I am able to view the Octree in the monitored_planning_scene topic (using rviz). **1.** I also found that I could specify collision objects using the PlanningSceneInterface Class. What is the difference between the two approaches? **2.** Also, what is the exact approach to using a PlanningSceneMonitor. In the planning scene tutorial, it is mentioned that the PlanninSceneMonitor is the elegant way to manage a Planning Scene. But, is there a tutorial for the PlanningSceneMonitor? **3.** I saw that the PlanningSceneMonitor has a protected function called "excludeWorldObjectFromOctree()" . Sometimes when I try to grasp an object (using xtion for obstacle avoidance), the plan fails since there is a potential collision between the fingers of the JACO arm and the object that I intend to pickup. I thought I could add it as a World object using the Planning Scene Interface (this I am able to do) and then use the "excludeWorldObjectFromOctree()" method to exclude the object from being considered for collision checking. Is there a more straight forward way of excluding a world object from collision checking? **4.** I have somewhat understood how you could modify the AllowedCollisionMatrix. But then, how do I ensure that this ACM is updated to the current Planning Scene? I expect that there is a method in PlanningSceneInterface like "updateAllowedCollisionMatrix()" ? Am I guessing right? or is there a serious error in my understanding? Please clarify! Thank you so much!

Ignored joint limits by MoveIt!

$
0
0
Hello, I am using MoveIt! for a simulated UR10 in Gazebo. When I try to tell the MoveGroup to move the end effector to a position (x,y,z,w), MoveIt! ignores the joint limits which are set in the launch file (-pi/2, pi/2, etc.). This leads frequently to a collision between the shoulder_link and the ground plane. Does anybody know why MoveIt! ignores these limits? If so, how can I resolve this problem? I am using ROS Indigo and Gazebo 2. If you will need more information, please advise :) Thank you very much in advance! Kind regards, Hannes **Update1: I am referring to this xacro file, the ur10_joint_limited_robot.urdf.xacro...**

error launching moveitsetup assistant

$
0
0
On launching move it setup assistant, I get an error message saying that the process has died. I have used sudo apt-get install ros-indigo-moveit source /opt/ros/indigo/setup.bash to install and setup the environment. I have also used `sudo apt-get update`, unfortunately the error persists amrith@amrith-ThinkPad-T420:~$ roslaunch moveit_setup_assistant setup_assistant.launch ... logging to /home/amrith/.ros/log/273d2cf4-e20f-11e6-9bc2-0021cc4b3caa/roslaunch-amrith-ThinkPad-T420-6923.log Checking log directory for disk usage. This may take awhile. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://amrith-ThinkPad-T420:46293/ SUMMARY ======== PARAMETERS * /rosdistro: indigo * /rosversion: 1.11.20 NODES / moveit_setup_assistant (moveit_setup_assistant/moveit_setup_assistant) auto-starting new master process[master]: started with pid [6935] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 273d2cf4-e20f-11e6-9bc2-0021cc4b3caa process[rosout-1]: started with pid [6948] started core service [/rosout] process[moveit_setup_assistant-2]: started with pid [6951] /opt/ros/indigo/lib/moveit_setup_assistant/moveit_setup_assistant: error while loading shared libraries: libmoveit_robot_state_rviz_plugin_core.so.0.7.3: cannot open shared object file: No such file or directory ================================================================================REQUIRED process [moveit_setup_assistant-2] has died! process has died [pid 6951, exit code 127, cmd /opt/ros/indigo/lib/moveit_setup_assistant/moveit_setup_assistant __name:=moveit_setup_assistant __log:=/home/amrith/.ros/log/273d2cf4-e20f-11e6-9bc2-0021cc4b3caa/moveit_setup_assistant-2.log]. log file: /home/amrith/.ros/log/273d2cf4-e20f-11e6-9bc2-0021cc4b3caa/moveit_setup_assistant-2*.log Initiating shutdown! ================================================================================ [moveit_setup_assistant-2] killing on exit [rosout-1] killing on exit [master] killing on exit shutting down processing monitor... ... shutting down processing monitor complete done
Viewing all 1441 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>