0
$\begingroup$

Rosanswers logo

dear all, i've finished the object manipulation with the amazing stack arm_navigation. that is, now my robot can grasp objects from a table while the robot base is fixed. however, due to the limited workspace of the arm, the robot can only grasp objects within a small region. it cannot even cover the whole table. so i'm wondering that, if we can plan a location for the robot base while do the arm motion planning? for example, the robot goes to the other side of the table to grasp objects there? according to my understanding about RRT, this is merely an addition of 3 degrees in the searching space, that is, the x,y, and rotation of the base. can we do this with the current planning_description_configuration_wizard? or does anybody have any hit for this task?

thanks in advance.

EDIT: dear pirate, although you've pointed a direction for me, i'm still confused about the details. do you mean that i need to modify the file MyRobot_planning_description.yaml generated by the wizard? if so, how should i modify? in the beginning of MyRobot_planning_description.yaml, it is:

multi_dof_joints:
  - name: world_joint
    type: Fixed
    parent_frame_id: base_link
    child_frame_id: base_link
groups:
  - name: left_arm
    base_link: base_link
    tip_link: left_link7

as you said, i need to add a P-R-P or P-P-R joint, where should i add this information?

besides, since i'm planning for the arm manipulation in the joint space instead of the task space, i need to first convert the goal pose to the joint space with IK. that means i must first determine the robot base's position, and then do the arm planning. in this way the whole planning is acturally split into two parts: first the planning for the base in SE(3), then the planning for the arm in the configuration space. however, i hope that the planner can treat the whole planning as one part.

don't know if i've put myself clearly :-( but i would really appreciate it if you could provide more details about your realization.

thanks again.


Originally posted by yangyangcv on ROS Answers with karma: 741 on 2012-11-11

Post score: 1


Original comments

Comment by bit-pirate on 2013-03-21:
Looks like an intern implemented a similar planner (new Darrt planner): http://youtu.be/4ocIvv64kwQ

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Yes and no.

As far as I can tell, your understanding of the RRT planner is correct. You can add 3 DOF for the base in your URDF, e.g. prismatic/prismatic/rotational or rotational/prismatic/rotational, modify the arm_navigation config files (output of the wizard) and let the OMPL planner of your choice do its work.

Actually, I did that and the result looks really fancy. :-) However, depending on your type of mobile base, the output plan may conflict with the constraints of your base. More specific, in my example I have a differential-drive base. The plan I get from the planner does not respect the "non-holonomic/rolling without slipping/don't move orthogonal to the current direction" constraint. The planner doesn't care about the transition from one point to the next. It only makes sure, each point its checking fulfils the constraints (e.g. joint limits, collisions).

In case you have a holonomic base, e.g. omni-wheels, powered casters, mercantum wheels, you might be able to do something useful with the output of the planner.

I think, MoveIt will be able to do you what you like to do. So, you could lean back and wait for the guys to do once again an awesome job, as they did with arm_navigation. :-)

/edit to answer your edit:

First, I modified my robot description (URDF) and added three fake joints (R-P-R) between a new "manip_start" frame/link and my robot's base_footprint link. Afterwards I built my custom arm_navigation from scratch using the arm_navigation_wizard. The only difference this time was, that I set the "manip_start" link as my new root (tip link stays the same). In this way the new fake joints get pulled in. Let me know how that goes.

In my case, I made it work for 8 DOF (3 in the arm, 2 in the torso, 3 in the fake base).


Originally posted by bit-pirate with karma: 2062 on 2012-11-11

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by yangyangcv on 2012-11-11:
thanks so much for your quick and helpful answer. i will give that a try. thank god, my base is a holonomic one. i'm also looking forward to the release of moveit!

Comment by yangyangcv on 2012-12-04:
dear pirate, i've edited my original post. could you kindly read it and give some hints for my new questions? thanks so much.

Comment by bit-pirate on 2012-12-07:
Done. Hope this helps.

Comment by yangyangcv on 2012-12-10:
thanks. seems things work fine for my 10 DOF robot(3DOF base+7DOF arm). the only problem is about trajectory filter. when i try to filter the trajectory produced by ompl, the process trajectory_filter_server dies with exit code -6. have you encountered this problem?

Comment by bit-pirate on 2013-01-13:
I remember an issue like this (haven't been using this set-up for a while). What happened to me from time to time, is that move_arm was crashing, because the filter couldn't process the trajectory. Seems like a bug in move arm, since it shouldn't crash just because the service call wasn't successful

Comment by bit-pirate on 2013-01-13:
I think it should just aboard the current request and then let you call the filter again or try a different trajectory.

Comment by Adolfo Rodriguez T on 2013-01-13:
The move_arm issue @bit-pirate mentions is ticketed as #5215. Issue contains patch with fix, if you're interested.

Comment by bit-pirate on 2013-01-13:
Sweet! Thanks! :-)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.