Arm_navigation/kinematics for simple arms

asked 2012-02-28 22:15:14 -0500

2062 ●24 ●47 ●55

updated 2012-02-28 22:15:35 -0500

Hi everybody,

I'm currently working with the arm_navigation suite in combination with a 7 DOF manipulator. Now, I would like to make it work with a much simpler manipulator, in my case with 2 DOF. However, I found several comments, e.g. on the turtlebot SIG mailing list and in questions like this one, that this is currently problematic/not possible with the normal arm_navigation stack.

I also followed the hint on the turtlebot sig list about the simple_arms stack used for turtlebot manipulation. The magic seems to happen in the simple_arm_server, where the orientation is modified according to the DOF (4-6) of the used arm.

Could somebody please give me some insight, what the main problems are, when using a simple arm?

I assume the/one issue is, that a 6D pose goal can lead to an overdetermined system, when using a <6-DOF manipulator. If this is one of the problems, I think using a different KDL solver could help us.

I took a deeper look inside the code and found out, that the KDL IK plugin used by arm_kinematics_constraint_aware utilizes KDL's chainiksolvervel_pinv solver. But KDL also offers the chainiksolvervel_wdls solver, which allows specifying task and joint space weights. The first can help handling overdetermined system, since it defines how much each error of a task space direction influences the overall error, which the solver tries to minimise. The latter can help handling underdetermined systems, since one can specify how much the error of each joint influences the overall error. Before jumping into coding, I'd like to hear other thoughts on this. Would this change help us? Are there other show stoppers in arm_navigation/kinematics when it comes to simple arms?

Btw, I know that there is also the option to use OpenRave's analytic IK solvers (see this question for more info), but I'd like to go with an optimisation based solver, such as the KDL ones.

edit retag flag offensive close merge delete

add a comment

answered 2012-02-29 06:36:19 -0500

egiljones
2026 ●5 ●18 ●36

I can't speak to the KDL portion of the question, but as for the rest of arm navigation I think that things should function correctly even with a very simple arm. There is no requirement of having an IK solver at all - you'll lose out to some extent in terms of interactivity, and you won't be able to pass pose goals into the planners, but joint space goals should function correctly. All of the tools already contain interaction modes where you can set joint goals directly - just stick to these modes and I expect that you'll get plans returned.

As for the rest of it, it's pretty straight-forward to implement a new IK plugin - just start with the existing KDL plugin as a base, make a copy, assign it a new class name, and make whatever changes you want to try. Then just declare the plugin in the kinematics_plugin.xml file either in your own package or in a code checkout of arm_kinematics_constraint_aware (if doing it in your own package make sure there's a direct dependency on kinematics_base in the manifest.xml). Then change over your autogenerated launch files to point at the new plugin and you should be able to try things out using the tools.

The larger issue is that it may be difficult to pick things up with such a simple arm. If you have relatively few DOF in your arm it generally makes sense to compensate for that in terms of degrees of freedom of the base to allow you to reach more positions - if you have a holonomic base you can then get 5 DOF in terms of end effector position. Our tools don't really extend to utilizing this kind of base movement to expand the reachability of a lower DOF manipulator, and I imagine this will lessen the usefulness of arm navigation for your low DOF arm.

Comments

Thanks for the elaborate answer! So, motion planning is done completely in joint space? Hence, it is not depending on a particular IK solver? In my case, I'm interesting in commanding pose goals. So, if I would implement the addressed IK solver, everything (planning, execution etc) should work well?

bit-pirate ( 2012-03-01 16:15:23 -0500 )edit

add a comment

Arm_navigation/kinematics for simple arms

1 Answer

Comments

Question Tools

Stats

Related questions

Arm_navigation/kinematics for simple arms edit

1 Answer

Comments

Question Tools

Stats

Related questions

Arm_navigation/kinematics for simple arms