set free_index for 7-dof robot's IKFast moveit plugin generation
Hi everyone,
I writing to ask a question about setting free joint index for a 7-dof robot's ikfast moveit plugin generation. I am running ROS kinetic on Ubuntu 16.04 and openrave master branch (commit). The sympy version I am using is 0.7.1 (matching openrave;s requirement).
The 7 dof robot I am working on consists of one standard 6 dof industrial robotic arm and a horizontal linear axis. Take the following 6-axis IRB6640 + linear axis for an example, the links info is:
name index parents
-----------------------------------------------------
base_link 0
linear_axis_base_link 1 base_link
linear_axis_zero 2 linear_axis_base_link
linear_axis_carriage 3 linear_axis_zero
linear_axis_robot_mount 4 linear_axis_carriage
robot_base_link 5 linear_axis_robot_mount
robot_base 6 robot_base_link
robot_link_1 7 robot_base_link
robot_link_2 8 robot_link_1
robot_link_3 9 robot_link_2
robot_link_4 10 robot_link_3
robot_link_5 11 robot_link_4
robot_link_6 12 robot_link_5
robot_tool0 13 robot_link_6
eef_base_link 14 robot_tool0
eef_tcp_frame 15 eef_base_link
robot_link_cylinder 16 robot_link_1
robot_link_piston 17 robot_link_cylinder
-----------------------------------------------------
name index parents
A snapshot of the dae visualization:
However, I've tried setting free_index to each of the indices, but the ikfast either popped up the following error (and I've tried running round_collada_numbers) or it takes 8 minutes or so to compute and then end with some errors:
__main__.CannotSolveError: CannotSolveError: need 6 joints
My question is: What would be the role of thumb in setting up this free index in ikfast generation for our 6-index industrial robot + linear axis setup, which is quite common in many real-world industrial applications?
FYI, I have documented a lot of details in my trial-and-error in an updated ikfast tutorial dedicated to Kinetic here [1], in the hope that it can help others.
This is not an answer, but see if the procedure in #q263925 makes any difference. It's written for 4dof, but just replace with the appropriate solver type. Using the
inversekinematicsdatabase has helped me get past weird IKFast errors before. Can't guarantee anything, but it's worth a try.