ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2013-01-30 10:59:21 -0500 | received badge | ● Popular Question (source) |
2013-01-30 10:59:21 -0500 | received badge | ● Notable Question (source) |
2013-01-30 10:59:21 -0500 | received badge | ● Famous Question (source) |
2012-09-11 04:44:51 -0500 | received badge | ● Famous Question (source) |
2012-09-11 04:44:51 -0500 | received badge | ● Popular Question (source) |
2012-09-11 04:44:51 -0500 | received badge | ● Notable Question (source) |
2012-08-15 14:32:07 -0500 | received badge | ● Famous Question (source) |
2012-08-15 14:32:07 -0500 | received badge | ● Notable Question (source) |
2012-07-20 06:05:44 -0500 | received badge | ● Popular Question (source) |
2011-09-02 11:28:00 -0500 | marked best answer | Trajectory filter failing for coordinated arms movement no activity in > 1 month, closing |
2011-08-05 05:16:30 -0500 | commented question | Trajectory filter failing for coordinated arms movement Sorry for the delay Sachin. My lab has an upcoming demo, and I been incredibly busy preparing. As soon as this demo is over I will send you everything, so you can look at it (2 weeks max). Thank you. |
2011-08-01 05:04:54 -0500 | commented question | Trajectory filter failing for coordinated arms movement I can email you a video, if you would like. |
2011-08-01 05:04:11 -0500 | commented question | Trajectory filter failing for coordinated arms movement The two end effectors are "colliding". |
2011-08-01 05:02:58 -0500 | commented question | Trajectory filter failing for coordinated arms movement We are using a custom robot. On Friday, my lab visited Rice and disgust the problem with the Kavraki Lab. Ioan Sucan suggested this may be a current limitation of the trajectory filter, since we are planning with multiple tips. From my understanding, much work is been done to expand arm_navigation, and maybe this is something you guys can look further into. |
2011-07-30 09:26:26 -0500 | marked best answer | Cooperative Robotic Arms? Jonathan, This is already possible, at least up to some extent. We have been using joint space planners for planning simultaneous motions of two 7-dof arms since the boxturtle release of ROS. Works like a charm. It's all in how you setup the different planning groups. Also, make sure that you select a planner that is compatible with multiple endpoints. We've had good results with lazy RRTs. Our usual workflow calls directly OMPL and the trajectory filters, but back in the day I tested it with the move_arm action as well. We never got around to exposing an IK solver for task space goals, but I don't see why that shouldn't be possible, and it's in our TODO list. One thing we have not (yet) incorporated in our motion planning is torso joints. Since these joints are located before the arms branch out, shortcut smoother filters don't work well. In such cases, using a planner with optimality guarantees, like RRT* would be the way to go. Also, using a weighted distance metric would allow to favor motions of more distal joints over proximal ones. @Sachin: What would be the scope of the multi-arm pipeline?. |
2011-07-26 11:26:52 -0500 | asked a question | Trajectory filter failing for coordinated arms movement Hello, I am working on coordinated motions with two 7 dof arms. I'm using diamondback. Currently, I am running only simulations via gazebo. I have been able to expose some basic move_arm functionality to two arms by creating an appropriate planning group and by using one joint_trajectory_action controller for handling control of both arms. I am using a JointPlanner via the RRT planner from ompl: Filter setup: The problems is on some coordinated movements, which bring the two arms close together, the trajectory filter doesn't seem to be constraint aware and it is removing parts of the plan which allow for collision free movement. So, in the end the arms are "colliding" with each other. I say "colliding" because they actual just pass through each other. Using rviz I can see the ompl RRT planner (prior to the filter) plans a collision free trajectory. But, after the trajectory filter snips alot of extra movement out the arms "collide". The "collisions" that happen are usually relatively minimal, i.e. just the tips of the end effectors pass through each other. I have tried different discretization values, but this doesn't help. I can increases the link padding, and this fixes the problem, but too much padding is unacceptable for our applications.
Any advice is much appreciated. Cheers, |
2011-07-21 03:09:33 -0500 | commented question | Cooperative Robotic Arms? Thanks for your info Sachin. Looking forward to the multi-arm pipeline. For now I will uses Adolfo's advice. |
2011-07-21 03:03:36 -0500 | commented answer | Cooperative Robotic Arms? Thank you for your info Adolfo. I will begin apply your advice - using the RRT planner. I will let you know how it goes. |
2011-07-20 11:48:58 -0500 | asked a question | Cooperative Robotic Arms? Hello, I am wondering if there is any ROS software developed or being developed for cooperative manipulator applications. For example, picking up large objects with two robotic arms. Currently, I have been experimenting with using move_arm software with our two 7-dof arms. Right now, I am sending separate goals (either joint position or pose) to each arm. Next, I would like to have cooperative motions, for example, both arms moving in unison. I have search throughout the ROS repositories and haven't found much (although I will continue looking). Any advice is greatly appreciated. Cheers, |
2011-07-19 23:04:07 -0500 | received badge | ● Student (source) |
2011-07-19 04:08:21 -0500 | answered a question | move_arm: occasional problems with trajectory filter Thank you Martin. I figured out the problem. I was publishing two different joint state messages - one for my 7 dof manipulator and one for my pan/tilt camera mount. What was happening is about half the time the move_arm functions were receiving the correct 7 dof joint states and the other half the time received the 2 dof pan/tilt joint states. All joint states must be published in the same message. The reason I used two different messages is that the pan/tilt mechanism was controlled using ptz-gazebo plugin and the 7 dof arm uses robot_mechanism_controller. I think the best thing to do is change the pt2-gazebo plugin to another robot_mechanism_controller. |
2011-07-08 06:56:39 -0500 | received badge | ● Editor (source) |
2011-07-08 06:55:52 -0500 | asked a question | move_arm: occasional problems with trajectory filter Hello, I am currently working on using move_arm (and associated packages) with our 7 dof manipulator. I am using diamondback. I used pr2_arm_navigation as a template and have generated all the appropriate config/launch files. The problem is when send a move_arm_joint_goal often I get an error from the trajectory_filter_server: This happens quite often, about half the time, but when it doesn't happen the goal is reached. I am not sure why trajectory_filter_server is not finding this joint in the raw joint state message only sometimes. Any advice is greatly appreciated. Other information: trajectory_filter_server launch: filter config file: Thanks, Jonathan |