Use Descartes on a 6-dof robot with linear track?

[yijiangh]

Is it possible to adapt descartes to plan for a 6-dof robot on a linear track (e.g., the snapshot from stomp demo [1] below)?

I think the key technical barrier would be the IKfast configuration. Is it possible to configure IKfast for this setup?

Thanks!

[1] https://github.com/ros-industrial/industrial_moveit

[Jmeyer1292]

The IKFastStateAdapter will handle it natively if you add the free joint in IKFast. You have limited-ish control over the discretization by default. If you write an extension to the robot model class, then you can probably implement more intelligent search policies if you need them.

I have used this with real hardware.

[yijiangh]

@Jmeyer1292 Thanks for the feedback! I'll implement it and come back with feedback to close this issue.

[yijiangh]

@Jmeyer1292:
The IKFastStateAdapter will handle it natively if you add the free joint in IKFast.
Could you please share how would you set the free joint index in IKFast generation?

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:

I have tried --baselink=3 --eelink=13 and --freeindex=11 or --freeindex=12, and ikfast kept returning this error:

TypeError: cannot determine truth value of
Abs(1.0*new_r00*new_r22 - 1.0*new_r11*new_r22**2) < 2.0e-8

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 applications?

I was following up the recent A5 development and found that a5_ikfast_lift_manipulator_plugin [1] did exactly what I want to achieve here. I'd really appreciate it if anyone could share your experience on this.

Thank you!

EDIT:

The error mentioned above:

TypeError: cannot determine truth value of
Abs(1.0*new_r00*new_r22 - 1.0*new_r11*new_r22**2) < 2.0e-8

is actually due to incorrect sympy version. While the default sympy version in Xenial is 0.7.6.1, openrave requires version 0.7.1 to work correctly. I have documented in an updated ikfast tutorial dedicated to Kinetic here [2], since we don't have an update-to-date ikfast tutorial for ROS-kinetic after moveit-ikfast [3] was archived and integrated into moveit-kinematics package under moveit! framework.

Correction:
ROS-kinetic does have an updated ikfast tutorial.

However, the ikfast popped up another error:

__main__.CannotSolveError: CannotSolveError: need 6 joints

I'm still confused about the free_index setting to get things right.

[1] https://github.com/ros-industrial-consortium/A5/tree/master/a5_ikfast_lift_manipulator_plugin

[2] https://github.com/yijiangh/framefab_mpp/blob/feature/abb_w_linear_track/framefab_robot/abb/framefab_irb6600/framefab_irb6600_support/doc/ikfast_tutorial.rst

[3] https://github.com/ros-planning/moveit_ikfast

[yijiangh]

Many thanks to @gavanderhoorn for pointing me to the inversekinematics database method to get around setting the free joint index in this ROS Answer post [1].

In the hope of helping someone else who encounters this problem, I've documented the resolution in an updated moveit-ikfast tutorial here (You can use rosdoc_lite to build it for fancier looking).

With this, I'll thank everyone here for helping me and close the issue.

[1] https://answers.ros.org/question/285611/set-free_index-for-7-dof-robots-ikfast-moveit-plugin-generation/?answer=285712#post-id-285712
[2] https://github.com/yijiangh/Choreo/blob/7c98fd29120e5ce75d2b8ed17bc49488ad983cb6/framefab_robot/abb/framefab_irb6600/framefab_irb6600_support/doc/ikfast_tutorial.rst

[gavanderhoorn]

Good to hear you got something to work, but why 'fork' that MoveIt tutorial? If you feel that this method works better than the one that is currently documented, it might be worthwhile to suggest that to the MoveIt developers and submit a PR with your updates.

[gavanderhoorn]

I would actually also suggest to really use the Docker image.

Installing OpenRave just to generate an IKFast plugin is not something I would recommend (or do). Using the Docker image completely removes the need to go through that.

[yijiangh]

@gavanderhoorn

Good to hear you got something to work, but why 'fork' that MoveIt tutorial? If you feel that this method works better than the one that is currently documented, it might be worthwhile to suggest that to the MoveIt developers and submit a PR with your updates.

I feel like my "fork" of the documentation is probably too wordy and it is written in a short amount of time just to record everything I did to make it work. And in my tutorial, I put a strong emphasis on 6+1 dof setting (and too many ABB examples from a private repo doesn't sound good for the official Moveit! tutorial), which might be only of interest within the ROS-I community. But I'll definitely work on submitting a PR to contribute to the original Moveit! tutorial after I polish it a little bit...

I would actually also suggest to really use the Docker image.

Installing OpenRave just to generate an IKFast plugin is not something I would recommend (or do). Using the Docker image completely removes the need to go through that.

But I think we don't have ROS-kinetic + Openrave docker image, do we? In my case, I really didn't want to reinstall ROS on my machine and I decided to give my existing src-built openrave a try, and surprisingly it worked like a charm. Thus, I documented it and I made a clear suggestion at the very beginning of the tutorial:

Before proceeding on building openrave from source, if you are using ROS-indigo. I recommend you to try installing a pre-cooked ROS-openrave package from personalrobotics/ros-openrave Docker image, following instruction from gvdhoorn in this post [1].

PS: In the ROS answer post [1], @hamzamerzic posted a very interesting online ikfast generator [2]. Although I haven't tested it yet, I think a web-based tool like this would be very helpful for many people who might suffer on the ikfast generation process.

[1] https://answers.ros.org/question/263925/generating-an-ikfast-solution-for-4-dof-arm/
[2] https://www.hamzamerzic.info/ikfast_generator/

[gavanderhoorn]

@yijiangh wrote:

@gavanderhoorn wrote:

I would actually also suggest to really use the Docker image.

Installing OpenRave just to generate an IKFast plugin is not something I would recommend (or do). Using the Docker image completely removes the need to go through that.

But I think we don't have ROS-kinetic + Openrave docker image, do we?

I'm not sure why we would need one?

In my case, I really didn't want to reinstall ROS on my machine

I'm not sure why you'd need to do that either.

and I decided to give my existing src-built openrave a try, and surprisingly it worked like a charm.

Of course. There is nothing magic about the OpenRave provided by the Docker image. The point is to be able to avoid 'polluting' your system with all the dependencies that are needed just to get OpenRave to compile, and then only use all of that for the 10 minutes you use OpenRave to generate your IKFast plugin.

I'd rather do a docker pull .. and docker run ... But that may be personal.

[yijiangh]

@gavanderhoorn wrote:

Of course. There is nothing magic about the OpenRave provided by the Docker image. The point is to be able to avoid 'polluting' your system with all the dependencies that are needed just to get OpenRave to compile, and then only use all of that for the 10 minutes you use OpenRave to generate your IKFast plugin.

I'd rather do a docker pull .. and docker run ... But that may be personal.

I have limited knowledge on docker but it seems to be very cool and convenient to use! (I did suffer from this kind of polluting in the past)

Thank you for clarifying this. I will give it a try and update the tutorial accordingly.